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I.  INTRODUCTION 


A.  BACKGROUND 

The  lessons  learned  from  the  history  of  the  modem  warfare  imposes  that 
technological  superiority  is  one  of  the  most  important  decisive  factors  in  the  conduct  of 
warfare,  providing  a  comparative  advantage  to  the  nation  that  owns  it.  Therefore, 
modernization  of  the  armed  forces,  and  acquiring  innovative  weapon  systems  has  been  a 
primary  consideration  in  many  nations’  defense  planning  strategies. 

On  the  other  hand,  the  defense  budgets  of  the  most  nations  have  been  exposed  to 
downsizing  throughout  the  past  decade,  thus  the  most  efficient  and  effective  use  of  tax 
payers’  money  and  providing  the  best  value  to  the  acquiring  agencies  has  been  the  most 
important  issue  for  defense  acquisition  organizations.  Furthermore  the  fast  prohferation 
and  high  obsolescence  rates  of  technology  comphcate  the  requirements  for  the  formal 
systems  acquisition  process:  The  weapon  systems  acquisition  process  should  be  robust  to 
incorporate  the  latest  technologies  into  system  solutions,  it  should  provide  the  best  value 
to  the  acquiring  organizations,  and  it  also  should  realize  best  utilization  of  limited  defense 
resources.  One  of  the  prerequisites  for  that  kind  of  acquisition  process  is  to  adopt  a  life- 
cycle  oriented  approach  in  terms  of  cost,  supportability,  and  operational  availabihty. 

In  order  to  explore  opportunities,  apply  theoretical  knowledge  base  into  practice, 
and  test  the  life-cycle  oriented  approach  to  weapon  systems  acquisition  decisions;  tins 
study  is  performed.  The  thesis  studies  all  the  issues  that  are  associated  with  adoption  of 
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the  life-cycle  oriented  approach;  then  estimates  the  probable  Life-cycle  Costs  (LCC)  and 
expected  operational  availability  of  a  major  weapon  system;  and  analyses  the  parameters 
that  affect  the  LCC  and  operational  availability  of  the  system  utilizing  a  case  study 
approach.  The  ATACMS  lA  Missile  System  Acqmsition  Program  has  been  adopted  as 
the  study  case. 

B.  THE  RESEARCH  QUESTIONS 

1.  Primary  Research  Question 

What  are  the  elements  of  the  LCC  for  the  major  weapon  systems  and  what  are  the 
primary  cost  drivers?  Are  they  controllable,  if  they  are,  what  are  the  methods  available, 
and  what  are  the  effects  of  performance  improvements  in  system  reliability, 
supportability,  and  maintainability;  and  in  the  logistics  processes  and  organizations 
associated  with  the  system  on  total  ownership  costs  and  system  operational  availability? 

2.  Secondary  Research  Questions 

1.  What  is  the  relationship  between  the  system  reliability  and  maintainability, 
and  the  operational  availability  and  LCC? 

2.  What  are  the  effects  of  the  learning  and  production  rates  on  system 
acquisition  costs? 

3.  What  are  the  effects  of  Innovative  Business  Practices,  such  as  Integrated 
Product  and  Process  Development  (IPPD)  on  system  LCC? 
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4. 


What  are  the  problems  experienced  in  the  traditional  major  weapon 


systems  acquisition  process? 

C.  SCOPE,  LIMITATIONS 

The  study  is  conducted  to  explore  the  LCC  drivers  for  the  major  weapon  systems, 
and  the  available  techniques  and  practices  that  would  enable  program  managers  to 
optimize  system  LCC  within  the  framework  of  case  study  on  the  ATACMS  lA  missile 
system.  The  cost  and  performance  data  figures  pertaining  to  the  system  are  assumed  by 
the  author  rather  than  being  actual  values. 

D.  ORGANIZATION  OF  THE  THESIS 

This  thesis  is  divided  into  five  chapters.  Chapter  I  provides  the  background,  the 
research  questions,  and  the  scope  of  the  study. 

Chapter  n  presents  a  comprehensive  overview  of  the  major  weapon  systems 
acquisition  process,  the  inherent  problems  in  the  process,  the  solution  approaches  adopted 
by  DoD  to  overcome  those  problems;  an  in-depth  discussion  of  system  development  and 
support  processes,  such  as  the  systems  engineering  process,  supportability  analysis. 
Integrated  Product  and  Process  Development  (IPPD)  approach  etc;  and  then  introduces 
life-cycle  costing  approach  for  major  weapon  systems. 
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Chapter  HI  builds  the  body  of  knowledge  for  cost  estimation  including  discussion 
of  estimating  techniques,  estimation  methodology,  and  estimation  tools  such  as  learning 
and  production  rate  curves,  sensitivity  analysis,  and  cost  risk  analysis. 

Chapter  IV  includes  the  application  of  life-cycle  cost  estimating  process  to  the 
ATACMS  lA  Missile  System,  and  analyses  such  as  sensitivity  and  cost  uncertainty  for 
estimated  Ufe-cycle  costs.  Finally,  Chapter  V  presents  the  conclusions  and 
recommendations  derived  from  the  study. 
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II.  OVERVIEW  OF  MAJOR  SYSTEMS  ACQUISITION  PROCESS 

AND  CONCEPTS 

This  chapter  of  the  thesis  is  organized  in  order  to  build  a  knowledge  base  about 
the  major  systems  acquisition  process,  including  the  new  process  mandated  by  the  rewrite 
of  DoD  5000.1  dated  October  2000.  These  include  the  system  development  process,  its 
underlying  concepts,  and  sub-processes  such  as  supportability  analysis;  and  life-cycle 
costing,  and  the  effects  of  innovative  business  practices  on  system  LCC. 

A.  MAJOR  SYSTEMS  ACQUISITION  PROCESS 

A  major  system  can  be  described  as 

....a  combination  of  elements  that  will  function  together  to 
produce  the  capabilities  required  to  fulfill  a  mission  need.  The  elements 
may  include  hardware,  equipment,  software,  or  any  combination  thereof, 
but  exclude  construction  or  other  improvements  to  real  property.  [Ref.  1] 

The  acquisition  process  of  those  major  defense  systems  is  an  iterative,  complex, 

and  detailed  process,  which  can  be  assmned,  from  the  global  perspective,  as  a  risk 

management  mechanism  that  tries  to  satisfy  the  agency  needs  in  the  most  mission 

effective  and  resource-efficient  manner. 

The  historical  roots  of  this  formal  acquisition  process  go  back  to  the  post-WW  H 
era,  however  the  process  was  articulated  in  1972  by  the  Commission  on  Government 
Procurement.  The  commission’s  concept  was  adopted  as  a  formal  acquisition  process  by 
issuing  The  Office  of  Management  and  Budget  (0MB)  Circular  A- 109  [Ref  2].  The 
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generalized  form  of  the  acquisition  process  is  shown  in  Figure  1 .  The  formal  acquisition 
process,  otherwise  known  as  the  life-cycle  management  process,  is  comprised  of 
consecutive  phases:  namely.  Requirements  Generation,  Concept  Exploration,  Program 
Defimtion  and  Risk  Reduction,  Engineering  and  Manufacturing  Development, 
Production,  Fielding/Deployment,  Operational  Support,  and  finally.  Demilitarization  and 
Disposal  pief  3].  In  addition  to  those  phases  or  intern  life  stages,  there  are  decision 
points,  called  milestones,  before  entering  each  phase  in  the  acquisition  process.  Those 
milestones  are  developed  to  ensure  the  program’s  success  throughout  the  system’s  life. 
At  those  milestones,  the  approvals  by  pertinent  authorities  to  enter  the  subsequent  phase 
are  made  and  the  exit  criteria  for  that  phase  is  specified  in  a  document  known  as  an 
Acquisition  Decision  Memorandum  (ADM). 
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Figure  1 :  Traditional  Acquisition  Process  [From  Refi  3J 


This  so-called  iterative  and  detailed  process  gets  started  with  the  determination  of 


a  requirement  or  an  operational  need  by  the  user  community,  in  that  context  operational 
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agencies  or  strategic  force  planners,  through  mission  needs  analysis.  The  primary  inputs 
to  the  mission  needs  analysis  process  are  national  military  pohcy  analysis,  threat 
assessments  for  adversaries  or  potential  adversaries,  or  changes  in  military  strategy  and 
doctrines.  Technological  improvements  and  iimovations  are  also  important  inputs  for  the 
mission  needs  analysis,  since  improvements  and  iimovations  in  science  and  technology 
may  redefine  how  the  military  performs  its  missions  both  in  organizational  and  technical 
terms.  It  is  important  to  state  at  this  point  that  all  the  new  or  redefined  Mission  Needs 
Statements  (MNSs)  may  not  result  in  new  acquisition  programs  to  develop  material 
solutions.  If  non-material  solutions,  such  as  organizational  restructuring  or  process 
reengineering,  are  available  to  satisfy  defined  needs  without  sub-optimization  behavior, 
then  these  alternatives  are  preferred  as  more  cost-efficient.  If  non-material  solutions  are 
proved  to  be  ineffective,  then  a  new  system  acquisition  is  considered  the  most  viable 
option. 

The  historical  facts  and  lessons  learned  about  major  acquisition  programs  denote 
that  the  success  of  the  program  is  hi^y  sensitive  to  correctly  analyzing  mission  needs 
and  carefully  converting  those  MNSs  into  Operational  Requirements  Documents  (ORDs). 
The  gap  between  user-defined  mission  needs  and  formal  MNSs  and  ORDs  is  filled  by  the 
discipline  of  system  architecting  and  engineering  [Ref.  4].  The  system  engineering 
process  will  be  overviewed  in  a  subsequent  section.  The  technological/conceptual  model 
of  the  acquisition  process  is  devised  to  refine  system  requirements  and  specifications 
iteratively,  rather  than  by  providing  system-specific  parameters  in  the  beginning  of  the 
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acquisition  process,  in  order  to  incentivize  technological  and  industrial  innovation  and 
develop  alternative  solutions  and  competition  as  much  as  is  cost  efficient. 

After  a  through  mission  needs  analysis  and  approval  of  the  Mission  Needs 
Statement,  the  decision  to  proceed  into  the  Concept  Exploration  phase,  i.e.  Phase  0,  is 
made  and  the  Exit  Criteria  firom  the  Phase  0  are  established.  The  essence  of  this  phase  is 
exploring  different  alternatives  to  develop  solutions  to  the  mission  needs.  In  that  phase  a 
formal  Analysis  of  Alternatives,  usually  utilizing  the  Cost  and  Operational  Effectiveness 
Analysis  format,  are  conducted,  and  Operational  Requirements  Documents  are  generated 
for  each  concept  that  is  selected  to  proceed  with  into  the  next  phase.  Provided  it  is  cost- 
efficient,  effective,  and  feasible,  proceeding  with  more  than  one  concept  into  the  next 
phase  is  encouraged,  since  these  will  provide  alternatives  and  increase  the  degree  of 
competition.  The  primary  tool  for  this  and  the  subsequent  phase,  which  is  Program 
Definition  and  Risk  Reduction,  is  using  short-term  parallel  contracts  with  the  responsive 
and  responsible  contractors,  or  with  Federally  Funded  Research  and  Development 
Centers  (FFRDCs). 

hr  the  Program  Definition  and  Risk  Reduction  phase  (PDRR),  the  eligible 
concepts  firom  the  concept  exploration  phase  are  narrowed  down  to  design  approaches 
and  the  prospective  systems  are  evaluated  closely  by  cost,  schedule,  performance,  and 
supportability  parameters.  System  prototyping,  demonstrations,  and  early  operational 
assessments,  especially  in  virtual  environments,  are  the  primary  tools  to  reduce  risk, 
which  is  inherent  in  any  system  development.  The  cost  drivers  in  the  life-cycle  of  the 
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system  are  identified  and  the  cost  data  to  support  program  budgeting  decisions  are 
developed  in  that  phase. 

hi  Phase  H,  which  is  the  Engineering  and  Manufacturing  Development  phase 
(HMD),  the  most  promising,  firom  the  perspective  of  performance,  cost,  schedule, 
supportability  fi'om  the  PDRR  phase,  and  the  design  approach,  are  evolved  into  a  stable 
design.  The  producibility  analysis  of  the  solid  design  is  performed  concurrently,  and  the 
manufacturing  techniques  for  the  proposed  system  configuration  are  developed  or 
maturated.  The  concurrent  engineering  approach,  which  will  be  discussed  later,  is 
utilized  in  that  phase.  This  approach  tries  to  evaluate  design,  producibility,  and 
supportability  issues  concurrently,  rather  than  iteratively.  In  order  to  test  the  proposed 
system’s  operational  capabilities,  an  optimum  quantity  of  system  is  manufactured  during 
Low  Rate  hiitial  Production  (LRDP),  which  also  helps  to  develop  reahstic  manufacturing 
cost  data. 

After  operational  testing  and  validation  of  the  system.  Low  Rate  Initial  Production 
is  evolved  into  Full  Rate  Production  (FRP),  which  will  incorporate  any  required 
modifications  to  the  design;  then  system  deployment  starts.  In  this  Operational  Support 
phase,  efforts  are  focused  on  sustainment  of  the  system.  Assessments  will  be  made  to 
evaluate  the  effectiveness  of  personnel,  logistics  support  (e.g.  spare  parts  supply  and 
maintenance),  and  any  potential  cost-effective  reliability  improvements  or  modifications. 
At  the  end  of  the  system’s  economical  life,  which  is  pre-planned  during  system 
development,  the  system  is  disposed  out  of  service.  The  disposal  and  demilitarization 
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activity  should  not  be  considered  as  only  dropping  the  system  out  of  inventory,  but  should 
be  considered  as  group  of  activities  that  aim  to  execute  the  disposal  process  with  Tninimal 
negative  impact  to  the  environment,  in  accordance  with  applicable  laws  and  regulations. 

As  stated  in  the  beginning  of  this  section,  the  underlying  concepts  of  this 
acquisition  methodology  go  back  to  the  post-WWII  era,  when  the  major  weapon  systems 
are  hardware-intensive  and  DoD  has  been  the  primary  weapon  technologies  developer. 
But,  the  times  have  changed;  now  most  major  weapon  systems  are  software-driven  (an 
extension  of  the  fly-by-wire-concept)  and  DoD  is  a  technology  integrator  and  user,  rather 
than  developer.  The  pace  of  technological  iimovation  is  very  fast  and  difficult  to  keep  up 
with.  This  paradigm  shift  profoundly  affects  the  success  of  the  formal  acquisition  process 
described  above.  Although  it  is  not  the  primary  topic  of  this  thesis,  the  writer  wants  to 
briefly  discuss  the  problems  with  the  aforementioned  acquisition  process. 

First  of  all,  the  nature  of  software  development  is  very  different  from  that  of 
hardware  development.  On  the  one  hand,  hardware  development  follows  a  linear 
development  cycle,  which  is  in  parallel  with  the  acquisition  process.  On  the  other  hanH 
software  development  efforts  are  spiral  rather  than  linear.  The  problem  arises  in  the 
synchronization  of  these  two  different  development  patterns  in  one  acquisition  challenge. 
Therefore  the  acquisition  strategy  for  software-intensive  major  weapon  systems  must  be 
tailored  to  solve  those  problems. 

The  other  problem  area  is  the  paradox  of  the  long  cycle-time  of  the  formal 
acquisition  process  versus  high  technological  obsolescence  rates.  In  today’s  acquisition 
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environment,  the  average  acquisition  time  for  major  weapon  systems  is  8  to  10  years. 
DoD  has  developed  initiatives  such  as  cycle-time  reduction  or  the  open  systems  approach. 
Although  both  are  veiy  promising  in  the  quest  to  resolve  the  issue  of  technological 
obsolescence,  these  initiatives  alone  are  not  sufficient  to  solve  the  problem.  A  more 
radical  approach  to  reengineering  the  acquisition  process  is  required.  Birkler,  et  al. 
propose  an  alternative  acquisition  process  to  acqxiire  state-of-the-art  technology  and 
innovative  systems.  This  process  is  called  the  dual  path  acquisition  methodology,  and  is 
depicted  in  Figure  2.  The  key  objectives  of  that  so-called  process  are  rapid  development 
of  new  operational  and  system  concepts,  acceleration  of  development  and  demonstration 
of  new  concepts  at  system  and  subsystem  level,  and  providing  early  provisional 
operational  employment  of  new  systems  well  before  completion  of  design  stabilization 
and  full  operational  testing.  The  so-called  dual  path  process  is  devised  to  work  in 
conjimction  with  the  current  acquisition  process  [Ref.  5]. 


Figure  2:  An  Innovative  Process  Proposed  by  RAND  [From  Ref.  5] 
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Considering  the  deficiencies  of  the  traditional  acquisition  process,  DoD 
reengineered  the  process  in  May  2000.  Basically,  the  new  process  separates  technology 
development  firom  system  development,  and  is  devised  in  order  to  enable  DoD  to  acquire 
innovative  systems  in  shorter  times  at  reasonable  cost  (Figure  3).  [Ref.  6]  Realization  of 
shorter  acquisition  lead  times  is  specifically  emphasized  in  the  process  because  of  high 
obsolescence  rates  and  proliferation  of  weapon  system  technologies.  The  cost, 
performance  and  schedule  risks  in  the  systems  acquisition  process  have  been  addressed 
by  promoting  use  of  mature  technologies,  evolutionary  requirements  generation 
(achieving  initial  operational  capability  as  soon  as  possible  and  developing  open  systems 
architectures  rather  than  finishing  the  full  system  development  phase),  and  developing 
cost  objectives  and  sticking  to  those  objectives  throu^out  the  systems  acquisition 
process.  At  highest  level,  the  new  process  includes  three  phases:  pre-system  acquisition, 
system  acquisition,  and  sustainment.  The  pre-system  acquisition  phase  is  comprised  of 
concept  and  technology  development  efforts;  those  efforts  and  verification  of 
technological  maturity  are  the  responsibility  of  the  science  community  rather  than 
acquisition  organizations.  Formal  acquisition  programs  start  only  after  the  science  and 
technology  organizations  verify  the  maturity  of  technology.  The  system  acquisition  phase 
is  comprised  of  system  integration,  demonstration,  manufacturing,  and  deployment  to 
achieve  Initial  Operational  Capability  (IOC).  The  acquisition  program  can  commence  at 
any  point  before  production  starts,  rather  than  following  a  mandatory  sequential  path  as  in 
the  old  acquisition  process.  The  last  phase  of  the  system  life-cycle  in  the  new  process  is 
the  sustainment  phase,  which  comprises  operations  and  support  activities  with  Full 
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Operational  C^ability  (FOC).  An  in-dqrth  evaluation  of  the  new  process  will  not  be 
discussed  because  it  is  beyond  the  scope  of  this  thesis. 
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Figure  3:  The  New  DoD  Acquisition  Process  (From  Ref.  6] 


B.  SYSTEMS  ENGINEERING  PROCESS  AND  RELEVANT  CONCEPTS 


1.  Systems  Engineering  Overview 


Systems  Engineering  can  be  defined  as 


...an  application  of  scientific,  engineermg,  and  managerial  efforts 
to  transform  an  operational  need  into  a  description  of  system  performance 
parameters  and  a  system  configuration  through  the  uses  of  iterative  process 
of  definition,  analysis,  synthesis,  design,  test  and  evaluation;  integrate 
related  technical  parametCTS  and  ensure  compatibility  of  all  ph3^cal, 
functional  and  software  interfaces  in  a  manner  that  optimizes  the  total 
system  definition  and  design;  and  integrate  reliability,  maintainability, 
safety,  survivability,  human  engineering  and  ofiier  such  factors  into  the 
total  engineermg  effort  to  meet  cost,  schedule,  supportability  and  technical 
performance  objectives.  [Ref.  7] 
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An  alternative  definition  of  the  systems  engineering  process  is  such  that 


...an  interdisciplinary  approach  encompassing  the  entire  technical 
effort  to  evolve  and  verify  an  integrated  and  life-cycle  balanced  set  of 
system,  people,  product,  and  process  solutions  that  satisfy  customer  needs.  . 
Systems  engineering  encompasses  the  technical  efforts  related  to  the 
development,  manufacturing,  verification,  deployment,  operations, 
support,  disposal  of,  and  user  training  for,  system  products  and  processes; 
the  definition  and  management  of  system  configuration;  translation  of  the 
system  definition  into  work  breakdown  structures;  and  development  of 
information  for  management  decision  making.  [Ref  8] 

These  two  alternative  definitions  of  systems  engineering  give  insight  into  the 
fundamental  characteristics  of  systems  engineering  practice,  which  are  discussed  in  the 
following  paragraphs. 


Systems  engineering  utilizes  a  top-dovm  approach  and  views  the  system  as  a 
whole,  in  contrast  to  the  bottom-up  approach,  which  is  utilized  in  traditional  engineering 
disciplines  such  as  mechanical  or  electrical  engineering.  The  primary  focus  areas  in  the 
systems  engineering  process  are  addressing  user  requirements  in  all  levels  of 
development  efforts,  and  interfaces,  either  subsystem  level  or  system  and  beyond  system 
level,  which  encapsulates  a  system-of-systems  concept.  The  difference  in  approaches  has 
sigmficant  effects  in  practice  such  that  the  top-down  approach  uses  hierarchical 
abstraction  models  to  ensure  successful  interface  of  the  subsystems,  but  does  not  warrant 
physical  realization  of  subsystems  or  components;  on  the  other  hand  the  bottom-up 
approach  guarantees  the  physical  realization  of  components  or  subsystems,  but  does  not 
ascertain  successful  interface  between  subsystems  or  components  of  a  system.  However 
both  methodologies  are  not  substitutes  for  each  other,  rather  they  are  complementary 


14 


methodologies  in  such  a  way  that  first  and  continuously  utilizes  systems  engineering 
methodologies  in  order  to  ensure  satisfaction  of  user  requirements  and  successfixl 
interface  between  system  elements,  and  reduce  complexity  and  total  ownership  costs  that 
utilizes  traditional  engineering  methodologies  to  realize  the  existence  of  components  or 
subsystems  of  a  system.  [Ref.  9] 

From  the  systems  engineering  perspective,  it  is  very  crucial  that  system 
developers  understand  user  needs  well,  and  develop  system  requirements  definitions 
correctly,  based  upon  those  well-imderstood  user  requirements;  the  ultimate  goal  of 
system  development  efforts  should  be  user  satisfaction  in  a  cost-effective  manner  [Ref. 
9].  The  system  requirements  must  be  well  defined,  specified  in  terms  of  functional 
performance  parameters,  and  be  traceable  throughout  all  levels  of  the  system.  The  lack  of 
understanding  user  requirements  correctly  in  the  initial  phases  of  the  system  development 
effort  may  lead  to  very  cost-intensive  engineering  changes  in  the  succeeding  phases  of 
system  development.  The  decisions,  based  on  perceived  user  needs,  in  early  stages  of 
system  development  efforts  when  the  system  specific  knowledge  is  limited,  determine  the 
cost  behavior  and  effectiveness  in  terms  of  both  operational  and  logistical  support  of  the 
system.  At  the  same  time,  the  ease  of  system  configuration  change  decreases  and  the 
resource  requirements  for  implementation  of  the  configuration  changes  increases 
exponentially  throughout  the  system  life.  This  system  development  pattern  is  shown  in 
Figure  4. 
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Figure  4:  System  Development  Pattern  [From  Ref.  9] 

The  Systems  engineering  process  is  a  life-cycle  oriented  approach,  which 
addresses  all  phases  of  system  life  from  conceptual  design  to  disposal.  In  traditional 
product  development  or  engineering  approaches,  the  emphasis  has  been  primarily  on 
system  acquisition  and  design  activities,  and  this  approach  has  generally  resulted  in  sub- 
optimization  without  considering  the  total  life-cycle  cost  of  the  system.  On  the  other 
hand,  in  the  systems  engineering  approach  the  development  efforts  are  focused  on 
reducing  total  ownership  costs  while  increasing  overall  system  effectiveness. 
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Systems  engineering  is  inherently  an  interdisciplinary  approach  and  requires 
teamwork  throughout  all  phases  of  the  system  development  cycle  in  order  to  ensure  that 
all  design  objectives  and  performance  parameters  are  addressed  in  an  efficient  and 
effective  manner.  This  so-called  team  approach  resulted  in  the  Integrated  Product  and 
Process  Development  (IPPD)  technique,  which  will  be  addressed  in  another  sub-section. 

2.  Systems  Engineering  Process 

Although  there  is  some  agreement  in  academia  and  industry  on  the  fundamental 
characteristics  of  the  systems  engineering  process,  there  are  many  different 
methodologies  available  in  different  domains  [Ref  9].  The  variance  in  the  methodologies 
comes  from  either  the  diverse  backgrounds  of  systems  engineering  practitioners  and 
application  areas  or  continuous  process  improvement  efforts.  In  this  subsection,  the  most 
popular  methodologies  will  be  briefly  evaluated. 

a.  Generic  Systems  Engineering  Process  Model 

This  generic  systems  engineering  process  model  primarily  reflects 
hardware  system  development  efforts  and  is  derived  from  the  hardware  product 
development  waterfall.  The  process  includes  inputs  and  outputs;  requirements  analysis; 
functional  analysis  and  allocation;  synthesis;  verification;  and  feedback  mechanisms 
between  those  sub  processes  (Figure  5).  This  process  model  has  been  very  successful  in 
the  past  in  developing  hardware-intensive  systems  such  as  major  weapon  systems,  but 
with  the  increasing  percentage  of  software  applications  in  system  architectures,  the  need 
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for  a  different  process,  which  will  reflect  a  software  development  pattern,  has  been 


evident. 
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Figure  5:  Generic  Systems  Engineering  Process  [From  Ref.  7] 

b.  Spiral  Development  Model 

As  mentioned  in  the  previous  sub-section,  this  development  model  has 
been  bom  out  of  the  need  for  a  different  process,  one  which  will  reflect  the  development 
pattern  of  software  or  software-intensive  systems  [Ref.  4].  The  stmeture  of  the  process 
reflects  one  of  the  fundamental  paradigms  of  software  engineering:  The  software  or 
software-embedded  systems  must  be  grown  rather  than  built,  which  addresses  the 
evolutionary,  time-phased  development  nature  of  software  or  software-embedded 
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systems.  Basically,  the  spiral  process  prescribes  developing  the  product  baseline  and 
realization  of  IOC  as  soon  as  possible,  and  evolution  of  the  product  according  to  the 
operational  difficulties  and  needs  experienced.  It  has  been  argued  that  this  approach 
would  dramatically  reduce  system  development  cycle-time  and  allow  the  incorporation 
state-of-the-art  technologies  into  later  versions  of  the  system.  In  fact,  DoD  has  modified 
its  traditional  acquisition  process  to  realize  those  objectives.  The  spiral  process  model  is 
shown  in  Figure  6. 


Figure  6:  Spiral  Process  Model  [From  Ref.  9] 
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c.  V  Process  Model 


The  fundamental  concepts  of  this  model  are  borrowed  from  the  National 
Aeronautics  and  Space  Administration  (NASA)  Software  Quality  Assurance  Program 
(SQAP),  which  was  used  in  the  1 980’s  by  the  agency;  the  process  is  also  called  “technical 
aspect  of  project  management”  [Ref.  10].  As  shown  in  Figure  7,  the  model  is  comprised 
of  two  major  sub-processes,  namely  the  decomposition  and  definition  sub-process,  and 
the  integration  and  verification  sub-process,  respectively,  for  each  arm  of  the  V  shape. 
The  model  is  intentionally  designed  to  develop  direct  correlation  between  both  arms  of 
the  V  shape  at  each  decomposition  level,  so  that  once  the  system  specifications  are 
determined  in  the  left  side  of  the  V,  the  verification  method  for  those  specifications  must 
be  determined  simultaneously.  This  model  is  a  meta-process  for  systems  engineering 
management  and  requires  the  tailored  application  of  the  generic  systems  engineering 
process  at  each  level  of  decomposition. 


Testing 


Figure  7:  V-Process  Model  [  From  Ref.  10] 
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d.  Hartley-Pirbhai  Methodology 


Hartley-Pirbhai  methodology  has  been  bom  out  of  the  need  to  solve 
problems  encountered  in  the  integration  of  the  systems’  software  and  hardware  elements 
in  the  avionics  industry;  it  has  been  utilized  in  many  real-time  software-embedded  system 
development  efforts  in  different  industries  [Ref.  11].  This  methodology  is 
complementary  to  spiral  development  model,  rather  than  an  alternative  systems 
engineering  process  and  should  be  used  concurrently  with  the  spiral  development  model. 

The  underlying  assumption  for  the  methodology  states  that  both  hardware 
and  software  components  of  the  system  are  highly  interrelated,  and  in  order  to 
successfully  perform  their  intended  function,  they  must  integrate  well.  Based  on  this 
assumption,  the  methodology  treats  the  system  as  a  whole,  including  both  software  and 
hardware  components,  and  develops  system  functional  and  architectural  specifications 
through  system  requirements  and  architecture  models  in  an  integrative  marmer,  rather 
than  following  different  paths  characteristic  of  traditional  system  development 
methodologies.  In  the  highest  level,  the  methodology  consists  of  a  requirements  model 
and  an  architecture  model,  which  define  respectively,  what  the  system  should  do 
(functions)  and  how  the  system  should  perform  those  functions  (architecture). 

3.  Open  Systems  Architectures 

Open  Systems  Architecture  (OSA)  has  been  defined  as  a  system  development 
concept  “that  implements  sufficient  open  specifications  for  interfaces,  services,  and 
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supporting  formats  to  enable  properly  engineered  components  to  be  utilized  across  a  wide 
range  of  systems  with  minimal  changes,  to  interoperate  with  other  components  on  local 
and  remote  systems,  and  to  interact  with  users  in  a  style  that  facilitates  portability”  [Ref. 
12].  In  more  explicit  words,  OS  A  is  a  system  or  product  development  strategy  that 
enables  the  system  developers  to  specify  modular,  interchangeable,  upgradeable  systems 
that  will  be  adaptable  to  technological  innovations  and  changes  in  the  user  requirements 
in  a  resource-efficient  manner. 

This  system  development  strategy  together  with  Single  Process  Initiative  (SPI), 
which  tries  to  eliminate  the  differences  between  commercial  systems  production 
methodologies  and  defense  systems  production  methodologies,  and  development  of 
flexible  manufacturing  systems  are  effective  enablers  in  reducing  total  ownership  costs 
and  acquisition  cycle-times  for  the  defense  systems.  As  a  matter  of  fact,  the  introduction 
of  a  new  major  system  acquisition  process,  which  adopted  a  time-phased  requirements 
and  incremental  system  development  methodology,  makes  the  application  of  OPA  an 
imperative  for  acquisition  strategy  plaimers. 

4.  Integrated  Product  and  Process  Development  Concept  and 
Concurrent  Engineering 

The  Integrated  Product  and  Process  Development  (IPPD)  concept  is  a 
management  technique  that  simultaneously  integrates  all  essential  acquisition  activities 
through  the  use  of  multidisciplinary  teams,  which  are  called  Megrated  Product  Teams 
(IPT)  in  order  to  optimize  the  design,  manufacturing  and  supportability  processes.  IPPD 
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facilitates  meeting  cost  and  performance  objectives  from  product  concq)t  through 
production  and  field  support  [Ref  13],  From  the  technical  viewpoint,  the  definition 
connotes  the  systems  engineering  process,  however  the  IPPD  concept  takes  the  teamwork 
orientation  of  the  systems  engineering  process  further,  to  include  not  only  design  and 
logistics-oriented  members,  but  also  include  the  budgeting  and  business-oriented  people 
(such  as  contracting  officers  or  contractor’s  persoimel)  into  the  product  development 
teams;  the  IPPD  concept  aims  to  improve  product-related  processes  by  concurrently 
including  design,  manufacturing,  and  support.  The  latter  objective  of  the  IPPD  concept  is 
called  “concurrent  engineering.  ” 

The  size  of  the  ff  Ts  should  be  based  on  the  nature  of  the  system  to  be  acquired, 
but  either  overcrowding  or  understaffing  the  teams  may  lead  to  undesired  results  in  the 
application  of  the  concept.  Overcrowding  may  slow  down  the  decision-making  process 
in  the  teams  and  cause  longer  acquisition  cycle-times  and  inefficient  use  of  lumted 
resources;  whereas'  understaffing  the  teams  may  lead  to  omission  of  important 
perspectives  that  may  result  in  catastrophic  consequences  such  as  unsatisfied  agency 
needs,  program  delays,  or  unsustainable  systems.  The  lessons  learned  from  file  major 
acquisition  programs  make  it  imperative  that  the  team  members  have  adequate  training 
and  the  required  skills  for  effective  team  dynamics.  The  other  point  that  deserves 
consideration  is  that  adding  new  members  to  any  system  development  team,  especially  for 
software-intensive  systems,  to  expedite  the  acquisition  process  makes  acquisition  cycle 
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time  longer  rather  than  shortening  it,  since  generally  the  most  efficient  team  members  are 
assigned  to  orientate  the  newcomer  to  the  process  or  team.  [Ref.  14] 

5.  Configuration  Management  And  Engineering  Changes 

The  concept  of  Configuration  Management  (CM)  arises  from  the  need  to  evaluate, 
and  track  the  changes  made  on  system  specifications  mandated  either  by  changes  in  initial 
requirements  or  technological  effects,  such  as  xmavailabihty  of  required  technology  and 
manufactunng  processes,  or  development  of  more  mission-effective  or  cost-efficient 
parallel  technologies;  and  to  ensure  the  successful  integration  of  those  changes  into  the 
whole  system  configuration.  CM  can  be  regarded  as  an  umbrella  activity  that  manages 
the  changes  throughout  the  system  life  from  system  development  efforts  to  sustainment. 
Before  discussing  the  CM  functions,  it  is  helpful  to  overview  briefly  the  drivers  of 
configuration  changes,  the  nature  of  the  changes,  and  their  effects  of  those  changes  on 
total  system  ownership  costs. 

One  of  the  major  drivers  for  configuration  changes  dm±ig  system  life  is  a  change 
in  the  requirements  which  started  the  acquisition  program.  The  requirements  generation 
and  system  engineering  processes  in  the  DoD  acquisition  process  are  structured  to 
miniimze  substantial  configuration  changes  in  the  system  through  validation  of 
requirements  at  all  levels  before  beginning  system  development  efforts.  However, 
experience  shows  that  there  have  generally  been  modifications  in  sj^tem  requirements, 
especially  in  changing  threat  environments.  The  changes  in  requirements  stem  either 
from  the  uncertainty  in  mission  environment  or  changes  in  the  operational  doctrines.  The 
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new  DoD  acquisition  process,  which  is  overviewed  in  the  first  section  of  the  chapter, 
adopted  evolutionary  requirements  and  open  systems  architectures  concepts  to  deal  with 
problems  stemming  from  this  domain.  However,  even  with  adoption  of  those  concepts, 
the  application  of  changes  in  system  mission  needs  to  system  requirements  may  prove  to 
be  costly,  especially  at  later  stages  of  system  development,  since  mission  needs  changes 
directly  affect  capstone  system  requirements. 

The  other  family  of  drivers  for  system  configuration  change  arises  from  the 
system  and  manufacturing  technology  domains.  The  writer  prefers  to  call  these  kinds  of 
change  drivers  as  technological  effects  that  may  have  either  positive  or  negative  triggers 
behind  them.  For  example,  the  unavailability  of  required  system  technologies  or 
manufacturing  technologies  might  lead  to  substitution  of  more  mature  and  available  ones, 
thus  changing  the  system  configuration  becomes  imperative.  On  the  other  hand, 
incorporation  of  some  other  parallel  technologies,  either  to  the  system  configuration  or  to 
the  manufacturing  process,  may  prove  to  be  more  mission-effective  and  cost-efficient 
through  value  engineering  efforts,  thus  changes  in  system  configuration  become 
imavoidable. 

The  main  determinants  that  affect  the  cost  of  configuration  changes  are  the  timing 
and  magnitude  of  the  configuration  change.  As  Figure  4  depicts,  the  cost  of  change 
increases  exponentially  as  the  system  life  progresses;  as  a  rule  of  thumb,  it  requires  10 
times  more  resources  to  implement  a  configuration  change  during  the  production  or 
sustainment  phases  than  implementation  of  a  similar  change  during  the  S5^tem 
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development  phase.  The  other  determinant  of  configuration  change  cost  is  the  magnitude 
of  the  change.  The  required  or  proposed  configuration  changes  may  be  either  be  local 
changes  i.e.  only  at  subsystem  level  that  does  not  affect  whole  system  behavior  and  does 
not  require  configuration  changes  in  other  levels,  or  global  changes  i.e.  that  require 
reconfiguration  of  other  subsystems  and  the  whole  system  for  successful  integration. 
However,  the  lessons  learned  show  that  most  of  the  configuration  changes  prove  to  be 
latter  ones,  and  require  adjustments  at  different  levels,  especially  in  software-embedded 
systems.  The  relationship  between  magnitude  of  change  and  cost  of  change  is  shown  in 
Figure  8. 


Figure  8:  The  Cost  versus  Magnitude  of  Change  ( Developed  by  the  Author] 

The  function  of  configuration  management  has  a  dual  pmpose:  the  first  being  to 
ensure  the  realization  of  developed  system  specifications  in  the  final  product,  product 
descriptions,  and  system-related  documents  such  as  technical  or  operational  manuals;  and 


26 


the  other  being  to  ensure  successful  integration  of  specification  changes  made  either  at 
subsystem,  component,  or  system  level  into  system  specifications  and  incorporate  those 
changes  into  system-related  documents  or  procedures  such  as  system  logistics  support 
functions.  As  stated  in  the  beginning  of  the  sub-section,  configuration  management  is  a 
continuous  activity  throughout  the  system  life-cycle;  therefore  configuration  management 
functions  should  be  performed  by  a  formal  organization  within  fhe  program  office  and 
system  modification  activities,  even  in  the  sustainment  phase,  should  be  coordinated  with 
that  organization. 

C.  SYSTEM  LIFE-CYCLE  COSTS  AND  COST  AS  AN  INDEPENDENT 
VARIABLE  (CAIV)  CONCEPT 

In  this  section,  the  life-cycle  costing  concept  and  its  elements,  and  the  effects  of 
system  reliability  and  innovative  business  processes  in  systems  acquisition  upon  system 
hfe-cycle  costs  will  be  briefly  discussed.  The  discussion  will  be  based  on  theoretical 
approaches  rather  than  empirical  studies,  and  is  intended  to  build  an  adequate  reader 
knowledge  base  concerning  those  concepts.  Throughout  this  thesis,  the  terms  “life-cycle 
costs”  and  “total  ownership  costs”  will  be  used  interchangeably. 

System  life-cycle  cost  is  defined  as  total  cost  to  the  acquiring  agency  of  the 
acquisition  and  ownership  of  the  system  over  its  full  life.  It  includes  cost  of  development, 
acquisition,  operation,  and  where  applicable,  disposal  pR.ef.  15].  In  the  acquisition  and 
cost  estimation  literature,  there  are  many  cost  terms,  such  as  flyaway  costs,  weapon 
system  costs  etc,  defining  some  portion  of  system  total  ownership  costs  that  may  cause 


27 


misimderstandings  for  readers  who  are  outside  the  acquisition  community.  Figure  9 
shows  the  relationship  and  hierarchy  of  those  cost  terms. 


Figure  9:  Cost  Terminology  {From  Ref.  161 

As  indicated  in  Figure  9,  Design-to-Unit-Production-Cost  (DTUPC)  is  comprised 
of  basic  unit  procurement  cost  including  recurring  production  costs,  but  excluding  initial 
spares  costs.  DTUPC  plus  non-recurring  production  costs  comprise  system  flyaway 
costs.  We^on  system  cost  is  formed  by  addition  to  flyaway  costs  of  any  item  costs 
required,  such  as  support  equipment,  but  &e  initial  spares  costs  are  excluded  in  we^on 
system  costs.  Addition  of  initial  spares  cost  to  weapon  S3«tem  costs  comprises  system 
procurement  cost.  Program  acquisition  cost  is  procurement  cost  plus  Research, 
Development,  Test,  and  Evaluation  (RDT&E)  cost  and  facility  construction  costs,  if 
required,  for  system  operation.  Program  acquisition  cost  plus  S3^tem  operation  and 
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support,  and  system  disposal  cost,  if  applicable,  is  called  system  life-cycle  cost  or  total 
ownership  cost. 

As  stated  in  the  previous  section,  the  decisions  made  in  the  early  stages  of  the 
system  development  effort  while  there  was  limited  system-specific  knowledge,  determine 
the  life  cycle-cost  behavior  of  the  system.  However,  the  costs  are  incurred  at  the  later 
stages  of  system  life,  they  are  established  by  system  development  decisions.  These 
system  development  patterns  are  shown  in  Figure  4.  One  of  the  acquisition  refonn 
initiatives,  which  is  the  Cost  As  an  Independent  Variable  (CAIV)  concept,  is  formulated 
to  control  resource  commitments  during  system  development  efforts.  Basically,  the 
CAIV  concept  can  be  defined  as  developing  life-cycle  cost  targets  for  the  system  to  be 
acquired  and  constraining  the  system  design  decisions  or  trade-offs  by  the  target  cost  of 
system  ownership.  Prior  to  the  CAIV  conc^t,  the  Design-to-Cost  approach  (DTC)  was 
very  popular  in  the  acquisition  community,  but  DTC  approach  has  been  primarily 
concentrated  on  controlling  system  procurement  costs,  rather  than  system  life-cycle  cost, 
whereas  the  CAIV  is  life-cycle  oriented,  which  tries  to  optimize  the  entire  system  life- 
cycle  cost  rather  than  a  portion  of  life-cycle  cost.  The  difference  between  these  two 
approaches  has  profoxmd  effects  on  system  cost  behavior.  For  example,  improving 
system  reliability  and  maintainability  to  optimal  levels  may  increase  the  cost  of  system 
development  efforts,  which  is  not  desirable  from  the  DTC  perspective,  but  improved 
reliability  and  maintainability  will,  in  long  run,  eventually  decrease  total  ownership  costs. 
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1. 


Discussion  of  System  Life-Cycle  Cost  Elements 


As  defined  above,  system  life-cycle  cost  (LCC)  or  system  total  ownership  cost 
(TOC)  is  total  of  all  die  costs  incurred  during  system  life.  The  major  components  of  the 
system  LCC  are  Research,  Development,  Test,  and  Evaluation  (RDT&E)  costs; 
Investment  Costs  which  include  Military  Construction  (MELCON)  costs,  and  Production 
and  Deployment  (P&D)  costs;  Operation  and  Support  (O&S)  costs;  and  Demilitarization 
and  Diq)osal  (D&D)  costs.  As  shown  in  Figure  10,  the  distribution  of  those  LCC 
elements  throughout  typical  system  life  is  such  that:  10%  of  LCC  is  RDT«feE,  30  %  of 
LCC  is  hivestment  Costs,  and  60%  of  LCC  are  O&S  and  D&D  costs  reflectively.  As  it 
is  clear  jfrom  the  proportional  cost  element  contnTiution  figures,  the  hipest  cost  driver  in 
LCC  is  O&S  costs;  therefore  the  system  developers  put  fiecial  emphasis  on  reduction  of 
O&S  costs  tiirough  improving  system  reliability  to  the  extent  feasible,  and  decreasing 
manning  and  logistics  support  requirements  for  the  system.  The  “smart  ship”  program  in 
the  US  Navy  is  good  example  of  those  kinds  of  efforts.  The  eiffect  of  design  fectors  such 
as  reliability  and  maintainability  on  LCC  will  be  discussed  comprehensively  in  Section  D. 


Figure  10:  LCC  Distribution  [  From  Ref.  161 
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In  the  following  sub-sections,  major  LCC  components  will  be  discussed  and  their 
cost  elements  will  be  listed  briefly. 

a.  RDT&E  Costs 

The  costs  associated  with  system  development  efforts  constitute  RDT&E 
costs  and  are  incurred  during  system  development  and  testing  efforts.  The  software 
component  of  any  system  actually  is  produced  in  that  period  since  software  reproduction 
costs  are  ignorable  relative  to  costs  incmred  during  software  development  efforts. 
Generic  RDT&E  Work  Breakdown  Structure  (WBS)  consists  of  those  cost  line  items. 

■  Project  management  costs 

■  System  test  and  evaluation  costs 

■  Data  collection  and  generation  costs 

•  System  engineering  and  integration  costs 

■  Demonstration  and  validation  costs 

■  Hardware  research  and  development  costs 

■  Software  development  costs 

■  Prototype  manufacturing  costs  etc. 

b.  Investment  Costs 

Investment  costs  cover  all  the  costs  incurred  to  field  the  system  to  the 
operational  units.  We  can  classify  investment  costs  into  two  major  categories;  military 
construction  costs  (MILCON),  and  Production  and  Deployment  costs  (P&D).  MILCON 
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costs  are  associated  with  construction  requirements  in  order  to  manufacture ,  operate ,  and 
support  the  system  throughout  the  system  life.  P&D  costs  refer  to  costs  incurred  for 
manufacturing  and  deployment  of  the  system  into  the  operational  units.  They  include 
costs  such  as  developing  manufacturing  equipment,  production  process  control  and 
quaUty  assurance  etc.;  the  recurring  manufacturing  costs;  costs  of  system  support 
equipment  and  training  equipment;  cost  of  initial  spares;  documentation;  and  the  other 
costs  required  to  make  the  system  deployable.  Generic  WBS  elements  for  Investment 
costs: 

■  MILGON  Costs 

■  Production  tooling  and  test  equipment  cost 

■  Production  set-up  cost  for  lots 

■  Pre-production  engineering  non-recurring  costs 

■  Recurring  production  costs 

■  Support  equipment  cost 

■  Initial  spares  cost 

■  Transportation  costs 

■  Training  devices  costs 

■  New  or  modified  facilities  costs 

■  Warranty  costs  etc. 
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c.  O&S  Costs 

O&S  costs  are  the  total  of  the  costs  associated  with  operating  and 
supporting  the  system  through  its  operational  life.  As  mentioned  previously,  the  largest 
portion  of  die  system  LCC  is  incurred  through  its  operational  life,  whereas  the 
opportunity  to  control  O&S  costs  is  very  limited  in  that  phase  of  the  system  life-cycle. 
Generic  Cost  Element  Structure  (CES)  of  O&S  costs  is  such  that: 

■  Persoimel  (Operations,  Maintenance,  Training  etc.) 

■  Unit  level  consumption  (Consumable  Materials,  Energy 
Consumption,  Spares  Replenishment,  Training  Munitions  etc.) 

■  Maintenance  Material  Costs  (0-level,  I-level,  D-level) 

■  Sustaining  Support  Costs  (Support  equipment  maintenance  and 
replacement.  Sustaining  engineering  support,  Software 
maintenance  costs  etc.) 

■  Indirect  Support  Costs  (Personnel  Support,  Installation  Support) 

d.  D&D  Costs 

D&D  costs  are  incurred  at  the  end  of  system  life,  and  associated  with 
disposal  of  the  system  with  minimal  environmental  effect.  The  increasing  level  of 
environmental  awareness  by  public,  restrictive  environmental  regulations,  and  security 
considerations  make  the  appropriate  disposal  process  an  imperative. 
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2. 


Effects  of  Innovative  Business  Processes  on  Total  Ownership  Costs 


So  far,  especially  in  section  B,  we  have  championed  innovative  business  practices 
such  as  system  engineering  methodologies,  concurrent  engineering,  integrated  product 
and  process  development,  and  time-phased  requirements  approach  etc.  At  this  point,  a 
pragmatic  question  rises  in  ones  mind;  what  would  be  the  effects  of  those  practices  on 
system  LCC?  Are  internal  rates  of  return  (IRR)  on  investment  for  those  practices  large 
enough  to  compensate  for  costs  related  to  application  o  ' those  practices? 

From  the  program  manager’s  perspective,  these  innovative  practices  can  be 
regarded  both  as  effective  variability  and  xmcertainty  reducers  and  as  productivity 
improvement  tools  throughout  the  system’s  life.  Although  using  group  techniques,  such 
as  IPPD  and  IPTs,  in  any  decision-making  process  may  lengthen  the  decision-making 
period  relative  to  one  functional  expert,  the  probability  of  erroneous  decision-making  that 
affects  the  future  behavior  of  any  system  decreases  dramatically  utilizing  the  group 
process.  Althou^  resource-intensive,  both  in  terms  of  time  and  financial  resources, 
application  of  vigorous  system  engineering  and  integration  methodologies  during 
requirements  definition  and  system  development  studies  through  will  pay  back  via  lower 
system  LCC  with  less  uncertainty  as  the  Figure  1 1  indicates. 
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Figure  11:  Impacts  of  Innovative  Practices  on  System  LCC  [From  Ref.  17] 

D.  SUPPORTABILITY  ANALYSIS  AND  ILS  CONCEPT 


As  mentioned  in  the  previous  section,  system  O&S  costs  constitute  the  major 
portion  of  the  system  LCC;  therefore  the  writer  concluded  that  it  would  be  beneficial  for 
the  study  to  explore  the  factors  that  affect  system  O&S  costs,  the  methodology  for 
conducting  predictive  supportability  analysis  during  system  development  efforts  (which 
help  system  developers  make  design  and  performance  trade-offs),  and  the  tools  currently 
available  to  conduct  consistent  supportability  analysis.  This  section  of  the  thesis  is 
organized  to  realize  that  objective. 

The  paradigm  in  the  system  development  process  has  been  changed  over  the  years 
from  a  “support  the  design”  concept  to  a  “design  for  supportability”  concept.  In  other 
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words,  supportability  considerations  have  been  inputs  to  the  system  development  process 


rather  than  post-process  considerations.  The  impacts  of  the  paradigm  shift  are  shown  in 
Figure  12.  The  paradigm  shift  in  the  process  has  introduced  the  concept  of  hitegrated 
Logistics  Support  (ILS)  to  the  system  acquisition  environment.  The  ILS  concq)t  can  be 
defined  as 


...a  disciplined,  unified,  iterative  approach  to  the  management  and 
technical  activities  necessary  to  integrate  support  considerations  into 
system  and  equipment  design;  develop  support  requirements  that  are 
related  consistently  to  readiness  objectives,  to  design,  and  to  each  other; 
acquire  the  required  support;  and  provide  the  required  support  during  the 
operational  phase  at  minimum  cost.  [Ref.  1 8] 


Basically,  ELS  is  a  management  function  that  tries  to  assure  deployment  of 
systems,  not  only  with  the  desired  functional  performance,  but  also  with  expeditious  and 
economically  optimal  supportability. 


Figure  12:  Impacts  of  Paradigm  Shift  in  System  Design  [From  Ref.18] 
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1.  Design  and  Organizational  Factors  Which  Affect  System 
Supportability  and  Availability 

The  factors  that  affect  system  supportability  can  be  classified  into  two  interrelated 
categories;  system  design  factors,  which  are  inherent  in  the  system  design,  and 
organizational  factors  that  define  the  environment  in  which  the  system  is  operated  and 
supported.  Some  of  those  design  factors  can  be  stated  as  rehability,  maintainability, 
usability,  and  transportability;  whereas  organizational  factors  address  the  capacity  and 
capabilities  of  the  legacy  organizational  structure  into  which  the  system  would  be 
deployed,  such  as  maintenance  and  supply  organizations  and  their  respective  capabilities, 
operator  and  technician  training  mediums,  or  available  transportation  modes  etc.  As 
stated  previously,  those  factors  interact  each  other,  and  the  result  of  this  interaction  can  be 
regarded  as  operational  availability  (Ao).  Basically,  operational  availability  is  the 
probability  that  a  system  or  equipment  will  be  available  to  operate  satisfactorily  under 
stated  conditions  in  the  actual  environment  when  called  upon.  System  Ao  has  been 
formulated  as  [Ref  19]: 

=  uptime Ji^ptime  +  downtime), 

where  uptime  corresponds  to  Mean  Time  Between  Maintenance  (MTBM)  and  downtime 
corresponds  to  Maintenance  Downtime  (MDT),  which  includes  Mean  Maintenance  Time 
(MMT),  Logistics  Delay  Time  (LDT),  and  Administrative  Delay  Time  (ADT).  Capacities 
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of  relevant  logistics  organizations  such  as  Cycle-Time  (CT)  and  Throughput  Rate  directly 
affects  LDT,  and  therefore  Ao. 

In  following  sub-sections,  the  design  and  organizational  factors  and  their 
interactions  that  affect  system  supportability  performance  will  be  overviewed  briefly. 

a.  Reliability  and  Spare  Parts  Determination 

Rehability  (R)  can  be  defined  as  the  probability  of  satisfactory 
performance  for  a  system  or  product  in  a  given  period  of  time  when  used  under  specified 
operating  conditions.  As  stated  in  the  definition,  system  reliability  has  four  elements: 
probability,  time,  satisfactory  performance,  and  specified  operating  conditions. 
Satisfactory  performance  parameters,  and  operating  conditions  must  be  specified  clearly 
in  system  ORD  documents.  The  determinants  of  system  reliability  are  system  failure  rate 
{k),  which  is  an  inherent  system  design  characteristic,  and  operating  time  (t).  The 
reliability  behavior  of  the  system  fits  negative  exponential  distribution  as  long  as  Mean 
Time  Between  Failures  (MTBF)  of  the  system  is  constant  during  operational  period,  and 
expected  reliability  of  the  system  at  its  operational  life  can  be  calculated  by  following 
equation:  [Ref  9] 
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When  there  is  more  than  one  system  in  any  operational  unit,  the  unit 
system  reliabihty  (composite  reliability)  can  be  calculated  by  inclusion  of  the  total  system 
number  (k)  in  the  above  formula: 

i?(r)  =  e"^ 

System  failure  rate  (X,)  is  the  reciprocal  of  MTBF,  and  for  some  hardware 
systems  the  behavior  of  X  throughout  system  life  is  called  the  “bath  tub  curve”  which  is 
shown  in  Figure  13.  As  stated  in  Figure  13,  X,  is  assumed  to  have  a  constant  value  during 
operational  period  of  the  system.  However  for  software  applications,  X,  behaves  quite 
differently  because  of  continuous  software  maintenance,  i.e.  bugging  and  debugging 
efforts  (Figure  14).  Overall  system  reliability  is  a  function  of  the  reliabilities’  of 
subsystems  and  components,  in  other  words  the  system  configxiration  determines  overall 
system  reliability.  From  a  reliabihty  perspective,  system  components  can  be  integrated  in 
parallel  or  serial  forms;  parallel  integration  enables  the  system  developers  to  increase 
system  reliability  through  increased  redundancy  in  the  system.  The  analytical  tools  that 
help  evaluate  system  reliabihty  during  system  development  efforts  are  Failure,  Mode, 
Effects,  and  Criticality  Analysis  (FMECA);  Fault  Tree  Analysis  (FTA);  critical  useful  hfe 
analysis;  the  stress  strength  analysis;  and  reliability  growth  analysis.  In  depth  discussion 
of  those  analytical  tools  is  beyond  the  scope  of  this  study. 
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Failure  Rate 


Figure  13:  Hardware  Component  Failure  Rate  Behaviors  [  From  Ref.  18] 


Infant  Mortality  Useful  Life  Period 

(Debugging)  (Maintenance) 


Figure  14;  Software  Components  Failure  Rate  Behavior  [  From  Ref.  9] 

The  number  of  system  spare  parts  needed  for  the  sustainment  of  the 
system  is  determined  by  the  composite  reliabilities  of  system  components  or  subsystems, 
system  operational  period,  and  desired  spares  availability  requirements.  Spares 
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availability  requirements  indicate  the  probability  of  spares’  availability  when  they  are 
needed.  The  relationship  between  those  parameters  is  indicated  in  the  following  formula: 


n=i 

^=2; 


n=0 


R(-]nRy 

nl 


where  S  is  the  number  of  spare  parts  in  the  stock;  R  the  composite  reliability;  and  P  is  the 
probability  of  availability  of  the  particular  item’s  spare  in  stock  when  needed.  The 
probability  distributions  derived  from  this  formula  fits  Poisson  distribution  with  mean 
value  of  -  InR,  i.e.  k*X*  t,  as  long  as  MTBF  for  the  specified  system  or  components 
follows  exponential  distribution.  When  determining  spare  numbers  at  unit  level  for  a 
particular  subsystem  or  component;  first  the  desired  protection  level,  that  is  P  in  above 
formula,  and  the  operational  period  must  be  specified.  The  length  of  the  operational 
period,  t,  depends  upon  different  parameters  such  as  stock  replenishment  period  for 
expendable  items,  or  Turn  Arorad  Time  (TAT)  for  repairable  items.  Given  the  required 
parameters;  protection  level  (P),  and  composite  factor  (k*X,*  t),  we  can  use  cumulative 
Poisson  table  in  order  to  determine  the  required  number  of  spares  for  a  particular 
component  or  subsystem.  However,  if  large  numbers  of  systems  are  involved  in  the 
spares  determination  process,  the  Poisson  values  approach  to  Normal  distribution  values 
as  the  result  of  the  central  limit  theorem.  In  the  cost  estimation  model,  the  spare  parts 
cost  will  be  calculated  by  this  theoretical  approach. 

The  system  reliabihty  is  an  important  parameter  that  affects  system  O&S 
costs  through  spares  requirements,  maintenance  actions,  and  the  determination  of  the  total 
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number  of  systems  to  be  acquired  in  order  to  guarantee  a  certain  number  of  systems  are 
operationally  available.  The  theoretical  relationship  between  system  reliability  and  TOC 
is  depicted  in  Figure  15.  As  is  clear  from  the  Figure  15,  the  improvements  in  system 
reliability  to  the  feasible  extent,  dramatically  decreases  system  LCC;  however  pushing  the 
envelope  for  system  reliability  beyond  feasible  technological  levels  may  require  huge 
commitments  for  R&D  activities  that  the  costs  savings  from  improved  reliability  may  not 
offset  those  commitments,  so  the  system  LCC  goes  up. 


COST 


Figure  15:  System  Reliability  and  LCC  Trade  -  Off  [From  Ref.  15] 
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b.  Maintainability 

Maintainability  refers  to  the  ease,  accuracy,  safety,  and  economy  in 
performance  of  maintenance  actions  required  to  sustain  the  system  during  the  operational 
use,  and  is  an  inherent  characteristic  of  system  configuration.  One  of  the  objectives  in  the 
systems  engineering  process  is  to  develop  a  system  or  product  that  can  be  maintained 
effectively  and  safely,  m  the  least  amount  of  time,  at  least  cost,  with  a  minimum 
expenditure  of  resources  (i.e.  people,  materials,  test  equipment,  and  facilities),  without 
adversely  effecting  the  mission  effectiveness  of  the  system.  System  maintenance 
requirements  are  derived  from  the  system  Maintenance  Concept  (MC),  which  is  based  on 
the  system  ORD.  The  system  MC  broadly  defines  levels  of  maintenance,  repair  pohcies, 
organizational  responsibilities  for  maintenance  actions,  logistics  support  elements  of  the 
system,  effectiveness  requirements  for  system  support,  and  environmental  conditions. 

All  maintenance  actions  pertaining  to  a  system  can  be  broken  into  two 
general  categories:  corrective  maintenance  and  preventive  maintenance  actions. 
Corrective  maintenance  actions  refer  to  unscheduled  maintenance  actions  performed  to 
restore  the  system  to  a  specified  level  of  performance  as  a  result  of  a  failure.  Preventive 
maintenance  actions  refer  to  scheduled  maintenance  actions  performed  to  retain  a  system 
at  a  specific  level  of  performance  by  providing  systematic  inspection,  detection, 
servicing,  or  the  prevention  of  impending  failures  through  periodic  item  replacements. 
Preventive  maintenance  actions  serve  to  keep  the  system  in  the  inherent  reliability 
performance  level,  rather  than  improving  system  reliability.  Similar  to  hardware  systems; 
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software  maintenance  actions  are  broken  into  two  categories:  adaptive  maintenance  and 
perfective  maintenance.  Adaptive  maintenance  refers  to  the  continuing  process  of 
modifying  software  in  order  to  make  it  compatible  to  changing  requirements  in  the  data  or 
processing  environment  within  the  original  architecture,  whereas  perfective  maintenance 
refers  to  software  modification  efforts  in  order  to  enhance  its  performance  through 
architectural  evolution. 

System  maintainability  is  assessed  through  maintainability  metrics,  which 
can  be  classified  into  three  categories:  maintenance  frequency  metrics,  maintenance 
elapsed-time  metrics,  and  maintenance  cost  efficiency  metrics.  Maintenance  ^frequency 
metrics  are:  Mean  Time  Between  Corrective  (Unscheduled)  Maintenance  (MTBMu), 
which  is  equal  to  MTBF  on  average  for  stable  systems;  Mean  Time  Between  Preventive 
(Scheduled)  Maintenance  (MTBMs);  and  Mean  Time  Between  Maintenance  (MTBM), 
which  is  average  time  between  all  maintenance  actions,  calculated  by  the  following 
formula. 


MTBM  =  - 

/mTBM^  ^ /MTBMs 

Maintenance  elapsed-time  metrics  refer  to  the  time  spent  Hnring 
performance  of  maintenance  actions.  Mean  Corrective  Maintenance  Time  (Met)  is  the 
average  time  required  to  perform  corrective  maintenance  actions,  whereas  Mean 
Preventive  Maintenance  Time  (Mpt)  refers  to  average  time  required  to  perform 
preventive  maintenance  actions.  Mean  Active  Maintenance  Time  (M)  is  average  elapsed 
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time  required  to  execute  preventive  and  corrective  maintenance,  and  calculated  by  the 
following  formula  in  which  the  “X,”  and  “fpt”  refer  to  failure  rate  and  scheduled 
maintenance  rate,  respectively: 

jlf  —  cr  )  '*'  PT ) 

Maintenance  cost  efficiency  metrics  refer  to  the  cost  part  of  maintenance 
actions  and  include  both  labor  costs  and  material  costs.  Although  there  is  no  standard 
metric  for  maintenance  cost  efficiency;  the  most  useful  of  those  metrics  are:  average 
material  cost  for  per  corrective  maintenance  action,  average  material  cost  for  per 
preventive  maintenance  action,  job  skill  requirements  for  maintenance  categories  at  each 
maintenance  level  etc. 

The  enabling  methods  and  tools  utilized  to  develop,  enhance,  and  test  the 
maintainability  performance  of  the  system  under  consideration  are:  Reliability-Centered 
Maintenance  (RCM);  corrective  vs.  preventive  maintenance  trade-off  analysis;  repair  vs. 
discard  analysis;  Level  of  Repair  Analysis  (LORA);  Fault  Tree  Analysis  (FTA); 
maintenance  task  analysis;  and  maintainability  prediction  techniques.  In  depth  discussion 
of  those  methods  and  tools  are  beyond  the  scope  of  this  study. 

c.  Usability 

Usability  refers  to  human  interface  with  system,  and  is  a  determinant  of 
system  manning  costs.  Usability  requirements  for  the  system  should  be  specified  in  the 


45 


s)i^tem  ORD,  and  should  reflect  the  anthropometrical,  psychological,  and  psychomotor 
properties  of  the  prospective  user  population.  The  general  objective  in  addressing 
usability  requirements  in  system  design  is  to  establish  system  design  criteria  that  will 
promote  simplicity  in  operation  and  maintenance  to  the  extent  possible,  in  order  to 
minimize  personnel  training  costs;  labor  costs;  probability  of  personnel  induced  system 
failures,  and  accidents,  so  that  the  system  LCC  can  be  minimized. 

The  most  important  usability  metrics  for  any  system  are  total  number  of 
persoimel  required  to  operate  the  system,  required  personnel  skill  levels,  training 
requirements,  human-mduced  failures  and  accidents,  and  the  quantity  of  system-mduced 
health  problems  in  the  personnel. 

d.  Transportability 

Transportability  of  a  system  addresses  the  requirement  for  the  system, 
subsystems  or  components  to  be  transportable  in  effective  and  efficient  manner  within 
available  transportation  modes  and  vehicles,  i.e.  hi^way  transportation,  airway 
transportation,  or  water  transportation;  and  is  directly  related  to  system  dimensional  and 
weight  parameters.  System  or  subsystem  transportation  initially  affects  system  LCC  in 
the  Production  &  Deployment  Phase,  at  which  the  acquired  systems  are  deployed  to  their 
units. 


During  the  sustainment  phase  of  system  life-cycle,  transportability 
performance  is  one  of  the  system  attributes  that  affect  the  O&S  costs.  The 
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transportability  effect  during  sustainment  phase  has  two  dimensions:  the  first  dimension 
refers  to  system  operating  costs  through  energy  efficiency  if  the  system  is  self  propelled, 
and  deployment  of  the  system  to  operational  sites  etc.;  and  the  second  dimension  refers  to 
system  support  costs  through  material  transportation  costs  for  system  support 
requirements.  System  transportability  performance  requirements  must  be  specified 
system  ORD,  and  must  be  integrated  with  system  maintenance  concept  and  Integrated 
Logistics  Support  Plan  (ILSP). 

e.  Organizational  Factors 

Organizational  factors  in  supportability  of  the  system  refer  to  the  legacy 
logistics  infi-astructure  throughout  all  levels  of  the  support  environment  in  which  the 
system  is  supposed  to  operate  and  be  supported.  Logistics  infrastructure  includes  the 
procedures,  processes,  and  people  associated  with  logistics  support  as  well  as  the  physical 
resources  such  as  support  facilities,  and  equipment. 

Systems’  ILSP  must  be  developed  in  such  way  that  promotes  efficient  and 
effective  utilization  of  the  support  infirastructure.  The  legacy  logistics  support 
infirastructure  should  be  evaluated  to  realize  improvements  that  enable  reductions  in 
system  support  costs.  One  area  of  interest  that  enables  the  PMs  to  reduce  support  costs 
and  increase  system  availability  without  investing  in  additional  numbers  of  systems  or 
system  spares  (in  order  to  meet  operational  readiness  goals),  is  legacy  organizational 
procedures  for  logisticss  support.  As  stated  previously,  operational  availability  could  be 
increased  by  reducing  MDT,  whose  main  elements  are  active  maintenance  time  (Mt), 
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ADT,  and  LDT.  ADT  and  LDT  are  directly  related  to  organizational  procedures  or 
processes  in  the  relevant  logistics  organizations.  By  improving  those  procedures  and 
processes,  one  can  reduce  ADT  and  LDT  for  any  system,  and  eventually  increase  system 
operational  availability.  For  instance,  changing  service  discipline  from  First  In  First  Out 
(FIFO)  to  Shortest  Path  Method  (SPM)  in  any  maintenance  organization  can  dramatically 
reduce  average  Cycle  Time  (CT)  or  Turn  Around  Time  (TAT)  for  that  organization. 

2.  Supportability  Analysis  Process 

After  briefly  reviewing  the  factors  that  affect  system  O&S  costs,  it  seems  helpful 
to  discuss  supportability  analysis  which  helps  evaluate  the  system  throughout  its 
projected  life.  Supportability  analysis  is  a  sub-process  within  the  systems  engineering 
domain  than  rather  being  a  separate  entity  in  system  acquisition  process. 

By  definition,  supportability  analysis  is  an  iterative  process  by  which  the  logistics 
support  necessary  for  the  system  under  consideration  is  identified  and  evaluated  within 
the  concept  of  ELS.  The  objective  of  supportability  analysis  is  to  aid  in  the  initial 
determination  and  establishment  of  supportability  criteria  as  an  input  to  design;  aid 
evaluation  of  various  design  alternatives;  aid  in  the  identification,  provisioning,  and 
procurement  of  various  elements  of  maintenance  and  support;  and  aid  in  the  final 
assessment  of  system  support  infrastructure  throughout  the  sustainment  phase.  [Ref.  18] 

The  supportability  analysis  is  a  continuous  effort  through  system  life.  However 
the  depth  of  the  analysis  and  analysis  tools  vary  at  different  stages  throughout  hfe-cycle 
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stages,  depending  upon  the  purpose  of  the  analysis.  Basic  processes  of  supportability 
analysis  are  problem  identification  and  needs  analysis;  selection  of  the  analysis  approach; 
establishing  evaluation  criteria;  selection  of  appropriate  analysis  techniques;  model¬ 
building  and  data  collection;  evaluation  of  alternatives  using  the  model;  and  analysis  of 
results. 


The  analysis  tools  utilized  during  the  performance  of  supportability  analysis  are 
briefly  mentioned  in  previous  subsection  in  the  context  of  their  relevant  supportability 
factors. 
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in.  COST  ESTIMATION 


Cost  estimation  can  be  defined  as  a  process  in  which  the  financial  resource 
requirements,  which  are  required  for  developing,  manufacturing,  fielding,  operating,  and 
sustaining  a  system,  are  explored  either  for  budgeting,  programming,  and  funding 
purposes,  or  analysis  of  system  effectiveness  and  analysis  of  alternative  system  designs. 
Cost  estimating  is  a  recurring  activity  throughout  system  life  rather  than  a  one-time 
activity  during  the  system  acquisition  period,  and  generally  the  quality  of  the  estimates 
increases  as  the  program  moves  through  the  phases  of  system  life-cycle  since  the  level  of 
uncertainty  decreases. 

The  available  methodologies  for  cost  estimation  are  classified  as  the  analogy 
approach,  parametric  techniques,  the  engineering  approach,  extrapolation  from  actuals, 
and  the  expert  opinion  approach;  those  techniques  will  be  discussed  comprehensively  in 
the  following  section.  Regardless  of  the  methodology  employed,  there  are  some 
prerequisites  in  order  to  develop  quahfied  cost  estimates.  First,  all  the  relevant  costs 
should  be  included  into  the  cost  elements  of  the  system,  which  refers  to  completeness  of 
the  estimate.  Second,  the  methodology  employed  in  order  to  develop  a  cost  estimate 
must  be  suitable  to  circumstances  such  as  availability  of  data,  and  the  purpose  of  the 
estimate  etc.,  and  must  consider  the  differences  with  analogous  systems’  cost  data  in 
technology,  and  socio-economic  conditions  (which  refers  to  reasonableness  of  the 
estimate).  Finally,  the  assumptions  upon  which  the  cost  estimates  are  based  and  cost 
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estimation  documentation  must  be  supportable  by  the  facts,  be  consistent  within  their 
own  context,  and  be  valid  (which  refers  to  consistency  of  die  estimate). 

The  quality  of  cost  estimates  developed  for  any  system  is  very  important  since  all 
the  resource  allocation  decisions,  and  system  effectiveness  evaluations  are  based  on  those 
estimates;  and  as  it  was  stated  previously,  the  cost  estimate  for  the  system  under 
consideration  must  be  iqjdated  throu^out  the  system  life-cycle  in  a  way  that  reflects 
future  costs  based  on  die  current  status  of  the  program,  and  identify  cost-drivers. 

A.  COST  ESTIMATION  TECHNIQUES 

In  this  subsection,  the  cost  estimating  techniques,  the  relationship  of  those 
techniques  to  system  life-cycle,  and  their  effectiveness  will  be  discussed.  As  pointed  out 
in  the  previous  section;  the  available  cost  estimating  techniques  are  the  analogy  approach, 
parametric  estimating,  the  engineering  approach,  extrapolation  from  actual,  and  the  expert 
opinion  approach. 
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Figure  16:  Cost  Estimation  Techniques  Utilization  through  System  Life  [From  Ref.  16] 
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All  of  those  techniques  are  not  mutually  exclusive;  they  can  be  utihzed 
concurrently  in  order  to  verify  the  cost  estimate.  However,  there  are  limitations  such  as 
unavailability  of  data  to  develop  detailed  estimates  when  utilizing  the  engineering 
approach  and  the  extrapolation  from  actuals  technique.  Figure  16  depicts  the  utilization 
of  these  techniques  throughout  system  life-cycle. 

Three  of  those  techniques,  the  analogy  approach,  parametric  estimating,  and  the 
expert  opinion  technique  (which  is  also  known  as  the  round  table  technique),  generate 
gross  estimates  rather  than  detailed  estimates.  The  engineering  approach  and 
extrapolation  from  actuals  generate  detailed  estimates  for  the  system  under  consideration. 

The  application  of  the  appropriate  estimating  technique  is  a  very  important 
determinant  for  the  quality  of  the  estimate;  the  appropriateness  of  the  technique  depends 
on  the  purpose  of  the  estimate,  phase  of  the  program,  and  availability  of  data  resources. 
The  required  level  of  effort  m  order  to  develop  a  cost  estimate  increases  exponentially  as 
the  level  of  detail  in  the  cost  estimate  increases.  All  of  the  estimating  techniques,  except 
for  the  expert  opinion  jqpproach,  utilize  mostly  quantitative  techniques,  while  the  expert 
opinion  approach  relies  on  the  subjective  evaluations  by  the  experts  who  are  asked  to 
estimate  probable  costs.  In  essence,  the  analogy  approach  also  utilizes  quahtative  and 
quantitative  techniques  concurrently,  since  adjusting  data  for  the  analogous  system 
requires  some  subjectivity. 

Presiunably,  all  of  those  techniques  originated  from  hardware-intensive  system 
development  efforts,  but  as  the  weapon  systems  get  more  software-intensive,  i.e. 
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embedded  weapon  systems,  those  techniques  need  adjustments  in  ways  that  would  reflect 
the  inherent  characteristics  of  software  development  efforts.  Relative  to  hardware 
systems,  software-intensive  systems  are  more  complex,  non-linear  in  nature,  and  the 
metrics  or  parameters  of  software  are  abstract  and  harder  to  understand. 

In  the  following  sections,  the  cost  estimating  techniques  will  be  discussed 
comprehensively. 

1.  Analogy  Approach 

The  analogy  approach  in  cost  estimation  utilizes  the  cost  data  of  similar  systems 
and  develops  a  gross  cost  estimate  for  the  system  imder  consideration.  The  method 
includes  a  judgment  process  in  which  the  similarities  and  differences  between  comparable 
systems,  and  their  cost  impacts  upon  the  new  system,  are  evaluated.  Based  upon  the 
results  of  his/her  judgment,  the  cost  estimator  develops  a  gross  cost  estimate  for  the  new 
system. 


As  the  name  of  the  technique  indicates,  the  comparable  systems  are  not  identical, 
rather  they  are  similar  and  therefore  the  apphcation  of  the  method  requires  some 
adjustments  to  accoxmt  for  differences  in  technology,  system  architecture,  production 
methodology,  techmcal  performance  variances  and  capabihties,  and  programmatic 
differences  such  as  acquisition  schedule,  acquisition  strategy,  and  socio-economic 
conditions. 
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Since  this  method  requires  subjective  evaluations  by  the  cost  estimator,  the  level 
of  imcertainty  in  the  estimation  is  very  high,  and  the  quality  of  the  estimate  is  highly 
sensitive  to  the  experience  of  the  cost  estimator.  In  order  to  make  the  judgment  process 
more  reliable,  the  cost  estimator  consults  with  the  engineers,  logisticians,  and  other 
technical  experts  related  to  systems  under  consideration,  and  develops  costs  estimates 
based  upon  feedback  from  those  functional  areas  of  expertise. 

Although  the  analogy  method  includes  a  high  level  of  imcertainty,  this  method  is 
useful  during  the  early  phases  of  the  system  acquisition  process  because  of  the 
unavailability  of  cost  behavior  data  to  develop  more  accurate  estimates  for  the  new 
system  and  thus  assess  its  practicality. 

2.  Parametric  Approach 

Parametric  cost  estimating  is  a  quantitative  technique  that  uses  statistical  analysis 
methods  in  order  to  develop  a  cost  estimate,  and  develops  Cost  Estimating  Relationships 
(CER)  using  system  physical  or  performance  characteristics,  i.e.  system  parameters.  The 
basic  assumptions  of  parametric  estimating  are:  the  cost  is  a  function  of  system 
parameters,  parameters  are  statistically  independent  variables,  meaningful  CERs  can  be 
developed  using  a  cost  and  performance  database  comprised  of  similar  systems,  and  the 
historic  cost  relationships  derived  from  the  cost  performance  database  is  valid  for  the  new 
system. 


55 


In  this  technique,  estimating  relationships  using  system  parameters  such  as 
weight,  power,  speed,  frequency,  and  thrust  etc.  are  used  to  predict  system  cost;and  the 
regression  analysis  is  the  fundamental  tool  for  developing  CERs.  The  parametric 
estimation  procedure  consists  of  statistically  fitting  a  line  or  function  to  a  set  of  related 
historical  data  and  then  substituting  the  appropriate  parameter  of  the  new  system  into  the 
resulting  equation.  The  data  used  to  derive  the  CERs  should  be  adjusted  against 
inflationary  effects,  other  programmatic  circumstances,  and  technological  differences. 

This  method  is  generally  used  during  system  life-cycle  phases  prior  to  FRP;  it  is 
used  when  system  performance  parameters  are  mature,  but  the  design  parameters  are  not. 

3.  Engineering  Approach 

The  engineering  method,  which  is  also  known  as  the  “bottom-up”  method,  is  the 
most  detailed  and  time-consuming  of  all  the  cost  estimating  methodologies.  However, 
the  increased  expense  of  this  method  is  generally  not  justified  by  its  significantly  greater 
accuracy,  since  individual  errors  in  each  Work  Breakdown  Structure  (WBS)  element  tend 
to  produce  a  large  error  in  the  overall  cost  estimate. 

Basically,  in  this  method,  the  cost  figures  are  developed  for  the  lowest  level  WBS 
elements,  i.e.  component  level,  from  either  actuals  or  by  utilizing  the  estimation  methods 
described  in  this  section,  and  then  the  figures  are  summed  up  throu^  the  upper  levels  of 
the  WBS  in  order  to  develop  a  system-level  cost  estimate.  The  adjustments  are  made  for 
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non-material  cost  elements  such  as  quality  assurance,  system  integration,  and  program 
management  efforts,  based  on  historical  cost  factors  for  the  similar  programs. 

Although  it  seems  very  consistent  and  objective,  this  method  also  has  some  level 
of  tmcertainty  just  like  all  of  the  estimating  methods.  The  uncertainty  results  either  from 
individual  errors  made  at  lower  levels  of  WBS,  as  stated  previously,  or  from 
rmprecedentedly  complex  system  integration  efforts.  System  integration  requires  much 
more  than  merely  putting  the  components  or  subsystems  together  to  form  a  system.  This 
method  can  be  utihzed  after  the  system  design  is  stabilized  and  the  system  WBS  is  clearly 
defined. 


4.  Extrapolation  Approach 

The  Extrapolation  technique  uses  the  actual  costs  incurred  during  the  previous 
production  of  the  same  system,  i.e.  prototype  recurring  costs  or  low-rate  initial  production 
recurring  costs. 

This  method  seems  the  most  reliable  cost  estimation  method  for  the  system  under 
consideration;  however  the  data  required  for  extrapolation  is  available  only  after  LRIP  of 
the  system  is  performed,  and  requires  some  adjustment  for  different  kinds  of  reasons. 
First  of  all,  the  system  may  require  some  modifications  prior  to  FRP  commencement  due 
to  operational  test  results,  so  the  system  may  differ  from  prototypes  or  LRIP  models  in 
some  aspects,  and  the  cost  impact  of  this  difference  might  be  greater  than  anticipated. 
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Therefore,  the  cost  analyst  should  consider  those  differences  and  their  cost  impacts  on 
stabilized  models. 

The  other  need  for  adjustment  stems  from  production  methodology  differences 
between  prototype  or  LRIP  and  FRP.  Prototype  production  is  rather  a  craft  type 
production  in  which  the  higher  level  engineers  or  technicians  are  deeply  involved  in 
manufacturing  process.  Production  methodologies  and  material  costs  are  not  yet 
optimized  and  the  capitalization  of  the  learning  ciure  effect  is  not  possible  since  there  are 
no  standard  procedures.  The  quantities  to  be  manufactured  are  so  small  tiiat  the  average 
unit  cost  for  prototypes  or  LRIP  units  are  substantially  higher  than  the  average  unit  costs 
for  future  FRP  umts.  On  the  other  hand,  during  FRP,  the  production  process  is  more  like 
an  assembly  line  in  which  the  optimal  levels  of  employee  mix  have  been  established, 
manufacturing  methodologies  are  standardized,  and  optimal  material  supply  systems  have 
been  developed.  The  end  result  of  those  improvements  is  substantially  lower  average  unit 
costs  through  minimization  of  labor,  material,  and  overhead  costs  relative  to  prototypes  or 
umts.  The  cost  analyst  should  also  consider  those  cost  impacts  in  performing 
extrapolation  for  the  future  cost  estimates. 

5.  Expert  Opinion  Approach 

Expert  opinion,  which  is  also  known  as  “round  table”  method,  involves 
qualitative  approaches  to  the  estimation  of  costs  related  to  the  system  under 
consideration.  This  method  heavily  relies  on  the  subjective  evaluations  of  domain 
experts,  such  as  software  engineers,  logisticians,  or  mechanical  engineers  etc.;  is 
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generally  employed  when  developing  cost  estimates  for  systems  or  research  projects 
which  are  very  innovative,  and  there  is  no  previously  developed  analogous  system  or 
similar  research.  Especially  in  the  software  domain,  where  technological  innovation  rates 
are  very  high,  and  the  products  are  inherently  complex,  abstract,  and  unique,  the 
evaluations  of  software  experts  are  the  foundation  of  cost  estimating. 

Since  the  method  involves  the  subjective  evaluations  of  the  domain  experts,  the 
level  of  uncertainty  is  very  high.  The  critical  factor  that  derives  the  reliabiUty  of  the 
estimate  is  choosing  credible,  experienced,  and  knowledgeable  experts.  The  other 
appropriate  measures  for  increasing  the  reliability  of  the  estimates  are  consulting  with 
more  than  one  expert  in  any  domain,  encouraging  the  experts  to  develop  weighing  scales 
for  the  cost-drivers,  and  asking  for  ranges  with  estimated  variation  rather  than  point 
estimates. 

B.  COST  ESTIMATION  TOOLS 

This  section  of  the  study  will  discuss  the  auxiliary  techniques  and  methods  which 
enable  cost  analysts  to  enhance  robustness,  reliability  and  accuracy  of  their  cost  estimates 
which  were  developed  by  utilizing  any  or  a  combination  of  the  basic  methods  described 
in  the  preceding  section.  The  author  of  this  thesis  prefers  to  classify  those  methods  imder 
the  domain  of  cost  estimation  tools,  since  those  methods  metaphorically  can  be  found  in 
the  toolbox  of  the  cost  analyst  and  are  independent  of  the  basic  technique  or  techniques. 
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Those  tools  are:  learning  curve  analysis,  which  is  mostly  relevant  to  recurring 
production  costs;  cost  uncertainty  analysis,  which  is  related  to  risks  involved  in  the 
developed  cost  figures;  and  sensitivity  analysis,  which  is  related  to  trade-off  issues, 
“what  if’  questions  for  the  system’s  technical,  programmatic  parameters,  and  their  cost 
impacts  on  LCC  imder  different  scenarios.  In  the  following  subsections,  those  tools  will 
be  discussed  in  detail. 

1.  Learning  Curve  Analysis 

Learning  curves  describe  the  empirical  relationships  between  output  quantities 
and  certain  input  quantities,  especially  in  recurring  production  activities  where  the 
learning  inducement  improvement  is  present  [Ref  20].  A  learning  ciuwe  depicts  the 
concept  that  the  cumulative  average  unit  cost,  or  unit  cost  of  the  item  manufactured, 
decreases  in  a  systematic  pattern  as  the  quantity  of  production  increases.  The  relationship 
between  the  production  quantity  and  the  cost  of  the  systems  produced  is  formulated  such 
that  the  unit  cost  or  cumulative  average  cost  of  the  system  decreases  by  a  common 
percentage  as  the  quantity  produced  doubles.  There  are  many  models  developed  for 
application  of  this  concept,  but  the  most  popular  one  is  the  log-linear  model,  which  is 
depicted  in  the  following  paragraph.  In  the  formula;  Yn  represents  the  cost  of  the  N-th 
umt,  A  represents  the  theoretical  cost  of  the  1®^  unit,  and  B  represents  the  slope  coefficient 
of  the  learning  curve. 


Y^=AN^ 
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The  slope  coefficient  of  the  learning  curve  can  be  calculated  by  following 


equation. 


B  = 


\n{LEARNING  _SL0PE) 
ln2 


The  learning  curve  theory  is  based  on  a  simple  principle  of  human  nature:  people 
learn  from  experience,  and  the  learning  phenomenon  increases  people’s  productivity  and 
efficiency.  There  are  two  factors  that  constitute  learning  phenomenon  in  the  production 
environment:  one  being  the  learning  in  literal  sense  on  the  part  of  labor  force,  and  the 
other  being  enterprise-wide  business  process  improvements  derived  from  lessons  learned 
from  practice. 

The  cost  impact  of  learning  curve  theory  during  system  life  cycle  can  be  very 
substantial  on  system  production  costs,  especially  when  a  large  number  of  systems  are 
required  to  be  manufactured;  this  cost  impact  should  be  factored  into  the  production  cost 
projections  for  the  systems  under  consideration.  On  the  other  hand,  there  is  a  negative 
relationship  between  the  employee  turnover  rate  and  achieved  learning  within  any 
organization,  therefore  when  factoring  the  cost  impact  of  the  learning  phenomenon  into 
system  production  cost  estimates,  the  cost  analyst  should  make  adjustments  for  employee 
turnover  rate. 

The  learning  curve  theory  may  have  also  have  an  impact  on  system  LCC  during 
the  sustainment  phase  in  which  system  maintenance  actions  are  performed.  However,  in 
general  practice,  the  system  maintenance  costs  are  estimated  by  the  mean  maintenance 
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time  parameter,  which  is  developed  by  statistical  experimentation  methods  and  therefore 
the  learning  phenomenon  is  indirectly  factored  into  calculation  of  mean  maintenance 
times. 


As  an  extension  to  the  leammg  curve  model,  the  log-linear  model  described 
above,  the  rate  adjustment  model  is  also  used  in  industry.  The  rate  adjustment  model 
basically  assumes  that  in  addition  to  learning  rate,  the  production  rate,  which  defines  the 
quantity  to  be  produced  in  certain  period,  also  affects  production  costs  systematically. 
The  relationship  formulated  at  following  formula  in  which  the  “Q”  represents  the 
production  rate,  “C”  represents  the  rate  coefficient,  and  the  other  variables  representing 
the  same  values  in  the  learning  curve  formula. 

Y,  =  AN^Q^ 

Similar  to  the  learning  curve  theory,  the  rate  coefficient,  C,  can  be  calculated  by 
the  following  equation. 

^  hijRATE  _SL0PE) 
ln2 

2.  Cost  Uncertainty  Analysis 

In  general,  cost  uncertainty  analysis  is  the  process  of  quantifying  the  cost  impacts 
of  the  rmcertainties  associated  "with  cost  estimation  methodologies  and  the  cost  data 
utilized  in  developing  cost  estimates.  These  vmcertainties  in  cost  estimation  arise  either 
from  inherent  uncertainties  in  the  data  collection  and  estimating  methodologies  involved 
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in  the  estimating  process,  or  from  uncertainties  in  program  and  system  parameters. 
Economic  uncertainties  that  influence  the  cost  of  technology,  the  labor  force,  geopolitical 
policies,  the  validity  of  the  assiimptions  made  by  the  cost  analysts  such  as  the  amount  of 
software  reuse  and  integration  efforts,  further  contribute  to  the  cost  uncertainty  inherent 
in  system  development  efforts.  The  uncertainties  in  program  and  system  technical 
parameters  and  their  cost  impacts  can  be  also  assessed  through  sensitivity  analysis,  which 
will  be  discussed  in  the  following  subsection.  [Ref  21] 

Because  of  the  aforementioned  imcertainties,  the  realization  the  probability  of  a 
point  estimate  developed  through  the  cost  estimation  process  is  literally  almost  zero. 
Therefore  the  cost  figures  are  stated  in  the  form  of  statistical  distribution  functions  based 
on  the  statistical  analysis  of  the  available  cost  data.  For  instance,  the  cost  figures 
developed  through  regression  analysis  application  are  used  in  the  form  of  a  normal 
distribution  function  with  a  standard  deviation  rather  than  a  point  estimate,  such  as 
expected  regression  value. 

As  discussed  previously,  the  system  cost  breakdown  is  comprised  of  many  cost 
elements  and  sub  elements  such  as  manufacturing  costs  and  its  sub-elements  etc.,  and  the 
overall  system  cost  is  estimated  through  the  summation  process  of  those  relevant  cost 
elements.  This  summation  process  affects  cost  xmcertainty  substantially  and  in  such  a 
way  that  the  variability  decreases  and  the  overall  cost  estimate  approaches  a  normal 
distribution  function  regardless  of  different  distribution  functions  used  in  the  sub-element 
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cost  ranges.  This  tendency  towards  normal  distribution  is  called  “central  limit  theorem”  in 
statistical  science  [Ref.  21]. 

Simulation  is  the  primary  method  for  conducting  uncertainty  analysis,  and  the 
Monte  Carlo  simulation  technique  is  a  successful  tool  used  to  develop  cost  figures  based 
on  defined  uncertainty  parameters.  Basically,  the  Monte  Carlo  simulation  produces 
random  numbers  according  to  the  statistical  distribution  functions  defined  in  the  system 
cost  elements,  repeats  this  process  until  the  desired  number  of  trials  is  achieved,  and  gives 
the  expected  value  with  statistical  central  tendency  metrics  such  as  standard  deviation, 
mean,  mode,  and  frequency. 

The  benefits  of  cost  uncertainty  analysis  for  the  decision-makers  can  be  classified 
into  three  categories:  establishing  cost  and  schedule  risk  baseline,  determining  cost 
reserve,  and  conducting  risk  reduction  trade-off  analyses. 

Baseline  cost  and  schedule  probability  distributions  for  a  given  system 
configuration,  acquisition  strategy,  and  cost-schedule  estimation  approach  provides 
decision-makers  visibility  into  potentially  high-payoff  areas  for  risk  reduction  initiatives, 
and  an  assessment  of  the  likelihood  of  achieving  the  budgeted  cost  for  a  given  schedule. 
Cost  uncertainty  analysis  also  provides  a  basis  for  determining  cost  reserve  as  a  function 
of  the  uncertainties  specific  to  a  system  through  an  assessment  of  mayimnm  cost 
magnitude  and  its  likelihood.  Besides  those  benefits,  the  cost  uncertainty  analysis  can  be 
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conducted  in  order  to  assess  the  effectiveness  of  alternative  risk  reduction  strategies  for 
reducing  system  cost  and  schedule  risks  and  their  respective  payoffs. 

3.  Sensitivity  Analysis 

In  general,  sensitivity  analysis  is  the  process  by  which  the  cost  impacts  or 
marginal  effects  of  variations  in  the  program  input  parameters  such  as  system  technical 
performance  and  supportability  requirements,  or  in  the  program  schedule,  are  examined. 
Sensitivity  analysis  is  also  known  as  “what  if’  analysis.  In  order  to  conduct  meaningful 
sensitivity  analysis,  sound  relationships  between  system  or  program  parameters  and 
system  LCC  must  be  developed  as  a  prereqmsite. 

Sensitivity  analysis  differs  from  cost  uncertainty  analysis  in  such  a  way  that  cost 
uncertainty  analysis  is  performed  within  the  given  program  and  system  parameters, 
whereas  the  sensitivity  analysis  is  performed  through  playing  with  given  input  parameters 
of  the  system  or  program.  Basically,  sensitivity  analysis  is  conducted  by  changing  one  of 
the  input  values  of  the  program  or  system  while  holding  other  parameters  constant,  and 
assessing  the  cost  impact  of  this  change  on  the  LCC  of  the  system.  However,  those  two 
methods,  uncertainty  analysis  and  sensitivity  analj^is,  are  complements  to  each  other 
rather  than  alternatives. 

Primarily,  sensitivity  analysis  is  conducted  during  system  development  efforts  in 
order  to  perform  life-cycle  cost-oriented  design  trade-offs,  which  aim  to  optimize  system 
design  in  terms  of  both  performance  effectiveness  and  cost  efficiency. 
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C.  COST  ESTIMATING  PROCESS 


The  generic  cost  estimation  process  includes  these  activities:  definition  and 
planning,  data  collection  and  analysis,  estimate  formation,  review  and  presentation,  and 
developing  final  cost  estimate  and  documentation.  [Ref.  22] 

1.  Definition  and  Planning  Activity 

Definition  and  planning  activity  includes  the  identification  of  the  cost  estimating 
purpose;  definition  of  system  parameters,  ground  rules,  and  assumptions;  selecting 
appropriate  estimating  approach;  and  formation  of  the  cost  estimating  team. 

Identification  of  the  purpose  of  the  cost  estimate  directly  affects  the  scope,  level  of 
detail  of  the  estimate,  selection  of  the  estimating  technique,  and  the  type  of  cost 
estimation  documentation  required.  As  stated  previously,  system  cost  estimation  studies 
are  conducted  for  two  main  reasons:  budget  formulation,  i.e.  developing  baseline  for 
resource  allocation  decisions,  and  comparative  studies  such  as  system  effectiveness 
evaluations  and  evaluation  of  design  alternatives  etc. 

Definition  of  system  parameters,  ground  rules,  and  cost  assumptions  provides  a 
basis  on  which  the  system  cost  will  be  estimated.  System  parameters  include  the  physical 
or  performance  characteristics  of  the  system,  whereas  ground  rules  and  assumptions 
include  acquisition  strategy,  program  schedule,  statements  and  conditions  that  affect  or 
are  assumed  to  affect  system  LCC,  and  assumptions  for  the  WBS  elements. 
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As  stated  before,  the  quality  of  the  estimate  is  directly  affected  by  the 
appropriateness  of  the  estimating  approach  utilized,  and  the  selection  of  estimating 
approach  depends  upon  the  purpose  of  estimate,  availability  of  data,  and  time.  In 
definition  and  planning  activity,  the  cost  analyst  tries  to  choose  the  best  approach 
depending  upon  the  constraints  mentioned  previously. 

The  cost  estimating  process  requires  teamwork  rather  than  one-man  activity; 
therefore  the  cost  analyst  should  determine  the  appropriate  mix  of  experts,  depending  on 
selected  estimating  approach,  and  Cost  Analysis  Requirements  Description  (CARD) 
document,  which  is  developed  during  description  of  system  parameters,  ground  rules,  and 
assumptions.  The  guiding  principle  in  building  a  cost  analysis  team  should  be  the  IPPD 
concept,  discussed  in  the  previous  chapter. 

2.  Data  Collection  and  Analysis 

In  this  phase  of  the  cost  estimation  effort,  the  data  required  for  the  cost  estimate 
is  collected  jfrom  alternative  data  resources  such  as  Defense  Acquisition  Executive 
Summary  (DAES)  reports.  Selected  Acquisition  Reports  (SAR),  price  indexes,  or  cost 
factors  handbooks  etc.  The  type  of  required  data  depends  on  the  selected  estimation 
approach;  however  it  includes  not  only  cost  data,  but  technical  and  programmatic  data  for 
the  system  as  well. 

The  collected  data  are  generally  in  raw  form  and  require  some  adjustment  process, 
which  is  also  known  as  the  normalization  process.  In  the  normalization  process. 
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inflationary  and  other  programmatic  effects  such  as  quantity,  technology  changes,  or 
differences  in  data  collection  methods  are  stripped  off  in  order  to  make  the  data  elements 
compatible  with  each  other.  For  instance,  all  then  year  or  different  constant  years  cost 
figures  are  converted  to  common  constant  year  figures.  Then  the  normalized  data  is 
analyzed  for  identification  of  statistical  properties. 

3.  Estimate  Formation 

Estimate  formation  is  the  process  by  which  the  chosen  estimating  approach  is 
applied  and  the  cost  model  for  the  system  is  developed  according  to  the  assumptions  and 
ground  rules  determined  in  the  definition  and  planning  phase.  The  normalized  data  and 
the  results  of  data  analysis  in  the  previous  phase  are  used  to  develop  CERs,  cost  factors, 
analogies,  and  learning  curves,  and  then  those  relationships  are  applied  to  the  program 
imder  consideration. 

As  the  final  step  in  the  estimate  formation  phase,  the  developed  cost  figures  are 
spreaded  fiscally  throughout  the  program  and  converted  to  then  year  cost  magnitudes  if 
the  pxupose  of  the  estimate  is  budget  formulation.  However,  if  the  puipose  of  estimate  is 
to  conduct  comparative  studies,  such  as  effectiveness  evaluation  or  evaluation  of  different 
design  approaches,  then  the  most  useful  method  is  to  convert  the  cost  figures  into  present 
value  using  appropriate  discoimt  rates. 
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4. 


Review 


In  the  review  phase:  the  robustness,  completeness,  reasonableness,  and  realism  of 
the  estimate  are  tested  through  sensitivity  and  uncertainty  analyses.  As  was  mentioned 
above,  the  sensitivity  analysis  is  conducted  through  playing  with  cost  model  input 
parameters  such  as  system  parameters  or  other  programmatic  parameters.  In  imcertainty 
analysis,  both  the  program  cost  and  schedule  risks  within  the  program  and  the  system 
parameters  are  assessed;  and  the  effectiveness  of  alternative  cost  and  schedule  risk 
reduction  initiatives  are  evaluated.  There  is  a  feedback  loop  between  the  definition, 
planning,  and  review  phases.  The  feedback  enables  cost  analysts  to  test  different  system 
and  program  parameters  through  sensitivity  analysis,  and  the  cost  and  schedule 
probability  assumptions  through  uncertainty  analysis. 

5.  Documentation 

Documentation  refers  to  consistency  of  a  cost  estimate,  and  is  rather  a  continuous 
activity  throughout  the  estimation  process  although  it  is  discussed  here  as  if  it  were  the 
last  step  in  the  estimation  process. 

As  it  is  evident  from  the  preceding  discussions  throughout  the  chapter,  the  cost 
analysis  process  requires  judgments  and  assumptions  by  the  cost  analysts  on  the  team. 
All  those  judgments,  assumptions,  and  their  rationale  must  be  supported  by  factual 
information  throu^out  documentation  activities. 
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IV.  ATACMSIALCC  COST  ESTIMATION 


A.  SYSTEM  DESCRIPTION 

1.  Mission 

The  Army  Tactical  Missile  System  (ATACMS)  Block  lA  was  developed  to  satisfy 
the  Army’s  urgent  need  for  a  long-range  weapon  that  operates  in  near  all-weather,  day  or 
night  conditions.  The  ATACMS  Block  lA  is  capable  of  effectively  engaging  high  value 
targets  at  ranges  well  beyond  the  capability  of  caimons,  rockets,  and  the  Army  ATACMS 
Block  I  missile  S5^tem,  and  is  required  to  be  efficiently  transportable  with  available 
transportation  modes;  air,  rail,  and  truck.  The  ATACMS  lA  will  effectively  attack  and 
defeat  Surface-to-Sxirface  Missile  (SSM)  units.  Air  Defense  (AD)  units.  Command, 
Control  and  Communication  (C3)  sites,  and  helicopter  Forward  Area  Rearming  and 
Refueling  Points  (FARRPs)  of  the  hostile  force. 

The  ATACMS  Block  lA  will  be  fired  fi'om  a  modified  M270A1  Multiple  Launch 
Rocket  System  (MLRS)  Launcher  and  will  be  deployed  within  the  ammunition  loads  of 
corps  MLRS  battahons  and  division  artillery  MLRS  batteries.  The  corps  MLRS  battahons 
will  provide  fires  for  General  Support  (GS)  of  the  corps,  and  GS-Reinforcing  (GSR)  to 
selected  divisions.  Divisional  MLRS  batteries  with  ATACMS  lA  will  provide  GS  to 
divisional  force. 
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2. 


Sub  System  Functional  and  Performance  Descriptions 


a.  Guided  Missile  Launch  Assembly  (GMLA) 

(1)  Guidance  and  Control  Section:  The  Guidance  and  Control 
Section  is  formed  by  Improved  Missile  Guidance  Set  (IMGS)  which  employs  GPS 
corrections  and  provides  all  navigation,  guidance,  autopilot,  and  communications 
functions  for  the  ATACMS  lA  missile.  Continuous  determination  of  position,  attitude, 
and  motion  are  provided  by  the  inertial  sensors,  associated  electronics,  and  software 
processing.  Guidance  and  autopilot  functions  are  provided  by  software  processing. 
Furthermore,  all  communications,  both  internal  and  external  to  the  missile,  are  provided 
by  IMGS  electronics  and  software  processing. 

(2)  Payload  Section:  The  primary  function  of  the  payload 
section  is  to  carry,  protect,  and  dispense  the  payload  of  M74  grenades  whose  total  weight 
is  350  pounds.  The  warhead  has  a  safe  and  arm  fuse,  and  a  Skin  Severance  System  (SSS), 
which  controls  the  release  of  M74  grenades  at  the  programmed  time.  The  SSS  includes 
an  arrangement  of  Flexible  Linear  Shaped  Charges  (FLSC),  which  split  the  payload 
section  skin  into  three  panels.  This  action  opens  the  payload  compartment,  allowing  the 
entire  load  of  grenades  to  disperse  over  target. 

Furthermore,  the  Payload  Section  has  an  embedded  GPS  antenna 
system,  which  is  designed  to  operate  in  the  high  temperature  environment  involved  with 
missile  flight,  and  to  perform  in  the  presence  of  threat  jammer  signals. 
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(3)  Propulsion  Section:  The  propulsion  system  furnishes  the 
energy  necessary  to  laxmch  the  missile  and  sustain  missile  flight  to  meet  ATACMS  lA 
altitude  and  range  requirements,  and  a  Solid  Rocket  Motor  (SRM)  provides  the  thrust  for 
the  missile.  The  SRM  consists  of  a  motor  case,  propellant,  insulation/liner,  nozzle,  and 
Igniter  Arm/Fire  Assembly. 

(4)  Control  Section  Assembly:  The  primary  functions  of  the 
Control  Section  Assembly  (CSA)  are  to  position  missile  fins,  provide  missile  flight 
power,  and  perform  selected  pyrotechnic  functions.  The  CSA  consists  of  a  Control 
Actuation  Set,  pyrotechnically  activated  electronics  and  control  power  batteries,  four  fin 
assemblies,  an  electrical  harness,  and  a  machined  boat-tail  structure.  The  CSA  is  attached 
to  the  aft  end  of  the  SRM  surrounding  the  motor  nozzle. 

(5)  Enclosure  Assembly  and  Launch  Pod:  The  Enclosure 
Assembly  and  Launch  Pod  (EALP)  serves  as  a  shipping,  handling,  transportation 
container,  and  launch  pod  for  one  missile  to  be  fired  firom  a  M270A1  launcher.  The 
EALP  is  sealed  for  environmental  protection,  and  is  equipped  with  desiccant  to  control 
hiimidity  within  the  enclosure. 

b.  MLRS  M270A1  Launcher 

MLRS  M270A1  Launcher  is  the  platform  from  which  the  ATACMS  lA 
missiles  are  fired,  and  is  capable  of  transporting  and  launching  two  ATACMS  missiles 
consecutively.  The  M270A1  is  comprised  of  a  modified  infantry  fighting  vehicle,  and  a 
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laimcher/loader  module.  The  tracked  vehicle  provides  a  multi-terrain  capability  and  is  the 
base  for  the  M269  lavmcher/loader  module,  which  houses  two  missile  pods,  each 
containing  one  missile.  Electrical/electronic  controlling  devices  are  mounted  in  the  M270 
for  aiming  and  positioning  the  M269  in  the  azimuth  and  elevation  axis. 

The  M270A1  is  designed  for  operation  with  a  crew  of  three;  a  driver, 
gunner,  and  a  chief  crew.  Additionally,  it  is  equipped  with  an  onboard  Fire  Control 
System  (FCS)  and  Improved  Position  Determining  System  (IPDS).  The  FSC  enables  the 
crew  to  program  fire  missions  while  enroute  to  launch  points,  reducing  mission  cycle 
time  for  the  system.  The  IPDS  determines  azimuth  reference  data  and  launcher  position 
data,  and  information  from  IPDS  along  with  targeting  information  are  transferred  to  the 
missile  during  pre-launch  phase. 

The  current  M270A1  MLRS  launchers,  which  are  issued  to  units  with 
deployment  of  ATACMS  I  missiles,  will  be  utilized  for  ATACMS  lA  missiles  without 
significant  modification  for  MLRS  launchers  except  interface  software  modification. 
Additionally,  launcher  operating  and  support  costs  of  the  MLRS  units  will  not  be  affected 
by  the  deployment  of  the  ATACMS  lA  missiles,  and  there  will  not  be  additional 
operating  personnel  requirements  for  the  system,  except  initial  orientation  training  of  the 
operating  personnel. 
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c.  Support  Equipment 

The  maintenance  concept  for  ATACMS  lA  requires  two  levels  of 
maintenance;  namely  ammunition  general  support  level,  and  depot  level  maintenance. 
The  required  support  equipments  for  those  maintenance  levels  are  Guided  Missile  Test 
Set  at  general  support  level  and  Missile  Test  Station  Equipment  (MTSE)  at  depot  level 
support.  In  the  succeeding  paragraphs  those  support  equipments  will  be  discussed  briefly. 

(1)  Missile  Test  Device  (MTD):  MTD  is  a  small  portable  test 
set  that  can  perform  electronic  checks  to  determine  the  serviceability  of  an  ATACMS  LA 
missile  in  its  EALP  while  not  on  board  a  launcher  without  affecting  the  integrity  of  that 
EALP.  It  will  be  utilized  at  ammunition  supply  points  and  at  ATACMS  lA  maintenance 
facilities. 


(2)  Missile  Test  Station  Equipment  Set:  Missile  test  stations 
are  used  at  Army  ATACMS  missile  facilities  to  perform  functional  and  diagnostic  testing 
of  ATACMS  lA  GMLAs.  A  missile  test  station  has  two  kinds  of  equipment;  Missile  Test 
Station  Equipment  (MTSE)  and  Missile  Test  Station  Augmentation  Equipment 
(MTSAE).  The  MTSAE  is  used  to  perform  detailed  diagnostic  testing  of  ATACMS  lA 
Inertial  Measurement  Unit  (EMU)  and  Control  Section  Assembly  (CSA),  and  to  print  data 
stored  in  tiie  GMTS. 
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d.  Training  Equipment 


The  ATACMS  lA  training  equipment  consists  of  a  Ml  65  Guided  Missile 
Traimng  Set  and  a  Guided  Missile  Test  Set  Trainer.  In  the  following  paragraphs,  those 
training  sets  will  be  introduced  briefly. 

(1)  M165  Guided  Missile  System  Training  Set:  The  function  of 
this  training  set  is  to  support  training  of  ATACMS  Explosive  Ordnance  Disposal  (EOD) 
personnel.  The  set  provides  familiarization  training  with  the  physical  aspects  of  the 
missile  and  the  location  and  identification  of  internal  components.  It  also  provides  a 
capability  for  training  EOD  personnel  to  determine  the  GO  or  NO-GO  status  of  the 
missile  Arm/Fire  and  Safe/Arm  Devices. 

(2)  Guided  Missile  Test  Device  Trainer:  The  Function  of  The 
Guided  Missile  Test  Trainer  is  to  support  training  of  Guided  Missile  Test  Set  Operators 
to  perform  GO-NO-GO  status  and  surveillance  testing  of  ATACMS  lA  missiles.  The 
trainer  is  physically  the  same  as  the  ATACMS  EALP  except  it  is  equipped  with  ballast  to 
stimulate  missile  weight,  a  malfunction  panel,  and  other  components  to  provide  missile 
malfunctions  to  Missile  Test  Device. 

e.  Computer  Software  Configuration  Items 

The  ATACMS  LA  missile  system’s  software  subsystems  consist  of 
approximately  600,000  lines  of  code  of  which  200,000  lines  are  developmental,  370,000 
lines  are  modified  and  40,000  lines  are  re-use  software  elements.  Addition  to  Ada 
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language,  which  is  the  primary  software  implementation  language  for  the  mission  critical 
computer  software  of  the  system,  the  other  languages,  namely  Jovial,  Assembly,  Fortran, 
and  Pascal,  are  utilized  in  development  and  integration  of  ATACMS  lA  software.  In  the 
subsequent  paragraphs,  the  software  subsystems  of  the  system  will  be  discussed. 

(1)  Navigation  and  Guidance  Computer  Operational  Flight 
Software  (NOFS):  This  program  is  responsible  for  guiding  and  navigating  the  missile, 
and  contains  an  executive  program  which  performs  alignment,  navigation.  Built  hi  Test 
(BIT),  auto  pilot,  guidance,  and  weapon  dispense  function.  The  guidance  set  software 
communicates  with  launcher  to  perform  its  functions. 

(2)  Navigation  and  Guidance  Computer  Inertial  Program 
Loader  Software  (NIPLS);  The  general  purpose  of  this  program  is  to  provide  automatic 
control  of  the  NOFS  upon  application  of  electronics  systems  power  to  the  missile. 
Functions  of  the  NEPLS  include  performing  power-up  BIT,  loading  fli^t  software, 
transferring  control  to  the  flight  software,  purging  classified  data,  and  providing 
communications  with  Navigation  and  Guidance  Computer,  Inertial  Sensor  Computer,  and 
the  launcher. 


(3)  Inertial  Sensor  Computer  Software:  this  software  sub 
system  is  responsible  for  communicating  with  the  gyros  and  accelerometers.  The 
fimctions  of  this  software  include  BIT,  alignment,  accelerometer  correction,  gyro 
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correction,  dynamic  motion  compensation,  coordinate  transformation,  attitude  reference, 
gimbal  control,  and  autopilot  filter  fimctions. 

(4)  Inertial  Program  Loader  Software  (IPLS):  the  functions  of 
IPLS  include  performing  power-up  BIT,  loading  ISCP  flight  software,  transferring  control 
to  flight  software,  and  providing  communications  with  Inertial  Program  Loading 
Software  associated  with  Navigation  and  Guidance. 

(5)  Embedded  GPS  Receiver  Computer  Program:  This 
computer  program  enables  the  missile  to  interface  with  GPS  satellite  system,  and 
provides  continuous  data  flow  to  the  NOFS  and  ISCS. 

(6)  Control  Actuation  System  Computer  Program  (CASCP): 
This  program  is  responsible  for  arming  Sohd  Rocket  Motor  (SRM),  command  destruct, 
enabling  War  Head,  controlling  fin  actuators,  BIT,  umbilical  break  wire  monitoring,  and 
communicating  with  Improved  Missile  Guidance  System. 

(7)  Guided  Missile  Test  Set  Software:  this  software  resides  in 
GMTS  and  performs  tests  on  the  missile  that  determine  the  missile’s  GO-NO-GO  status. 

(8)  Missile  Test  Set  Software:  This  computer  program  resides 
in  Missile  Test  station  equipment  and  performs  diagnostic  tests  for  missile  at  depot-level 
maintenance. 
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(9)  M270A1  Launcher  Software:  The  Launcher  software  is 

embedded  in  launcher’s  PCS  and  IPDS  systems  and  enables  those  systems  to  perform 
their  intended  functions. 

3.  System  Operational  Concept 

As  stated  previously,  the  ATACMS  lA  missile  system  will  be  deployed  within  the 
ammunition  loads  of  corps  MLRS  battalions  and  divisional  MLRS  batteries,  and  will  be 
fired  against  hi^  value  targets  such  as  enemy  Surface-to-Surface  Missile  Units; 
Command,  Control  and  Communication  sites  etc.  which  are  beyond  the  ranges  of 
traditional  artillery  weapons. 

The  deployment  plan  of  the  ATACMS  lA  missile  system  was  formulated  to 
minimize  the  cost  of  fielding  by  fielding  of  the  system  to  existing  MLRS  units  with  no 
additional  personnel,  and  minimal  additional  training,  rather  than  developing  new  units, 
and  new  Military  Occupational  Specialties  (MOS).  In  this  study,  the  numbers  of  fielded 
systems  are  considered  cumulatively  rather  than  on  a  unit-by-unit  basis,  because  of 
security  considerations. 

The  ATACMS  lA  missiles  have  four  modes  and  states;  storage,  pre-laimch, 
flight,  and  dispense.  The  EALPs  will  be  stored  at  ammunition  supply  points,  and  aside 
fi-om  training  and  military  exercise  piuposes,  the  missiles  will  be  issued  to  MLRS  units 
during  contingency  times.  During  storage  mode,  the  EALPs  will  be  stored  in  outside 
covered  storage,  and  no  major  preventive  maintenance  will  be  required  except  annual 
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inspections,  surveillance  testing,  and  corrosion  control  activities,  if  required.  The  pre¬ 
launch  mode  begins  when  the  Guided  Missile  Launching  Assembly  (GMLA)  is  loaded 
onto  the  M270A1  Launcher  and  ends  with  missile  launch.  The  activities  involved  with 
this  mode  include  movement  from  the  launcher  re-load  point  to  the  missile  firing  point, 
upload  of  the  missile  flight  software,  conduct  of  pre-launch  procedures,  and  alignment 
transfer  from  the  launcher  to  the  ATACMS  lA  missile.  The  flight  mode  involves  all  the 
missile  activities  during  time  period  from  launching  to  the  destination,  target  area.  The 
payload  of  the  missile  is  dispensed  over  the  target  area  during  the  dispense  mode. 

M270A1  MLRS  Launchers  will  be  stationed  at  the  MLRS  units,  and  were 
designed  to  be  operated  by  the  crew  of  three;  a  driver,  a  gunner,  and  a  crew  chief.  As 
stated  previously,  the  fielding  of  the  ATACMS  lA  missiles  will  not  require  additional 
O&S  costs  for  the  M270A1  MLRS  Launchers,  thus  the  O&S  costs  for  the  launchers  are 
excluded  in  the  LCC  estimation  for  the  ATACMS  lA  missiles.  The  deployment  of 
missiles  system  >vrll  only  require  initial  orientation  training  for  the  current  launcher 
operators. 


4.  System  Support  Concept 

The  ATACMS  lA  system  will  utilize  the  standard  Army  support  structure  to  the 
maximum  extent  possible  and  in  accordance  with  the  Integrated  Logistics  Support  Plan 
for  the  system.  The  support  concept  for  the  system  differentiated  between  the  hardware 
sub-  system  support  and  software  sub-system  support.  The  initial  spares,  repair  parts,  and 
required  documentation  for  the  system  and  sub-systems  will  be  provided  with  the 
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deployment  of  the  systems.  The  initial  spares  and  repair  parts  requirements  will  be 
calculated  through  operational  availability  target  values,  considering  the  capacities  and 
Turn  Around  Times  (TAT)  of  the  relevant  support  facilities. 

a.  Hardware  Support 

The  ATACMS  lA  hardware  maintenance  will  be  performed  at  two  levels; 
Ammunition  Supply  Support,  which  is  equialvant  to  General  Support  (GS)  and  Depot 
Level  Maintenance  (D).  The  peculiar  maintenance  and  support  activities  for  system 
hardware  elements  will  be  discussed  briefly.  The  values  of  supportability  performance 
parameters,  such  as  MTBF,  MTBM,  Mean  Maintenance  Time,  and  maintenance  material 
and  personnel  costs  will  be  provided  in  the  CASA  model  inputs. 

(1)  Guided  Missile  Launch  Assembly  (GMLA):  GS 
maintenance  support  will  be  performed  by  the  Support  Maintenance  Company  utilizing 
55  and  27  series  of  MOS  personnel.  Support  maintenance  personnel  (MOS  55)  will 
replace  desiccant,  spot  point,  and  perform  limited  repair  of  damaged  external  structural 
items,  covers,  and  panels.  Support  personnel  (MOS  27)  will  check  a  sample  of  missiles 
annually  for  GO  or  NO-GO  status  utilizing  the  MTD.  GS  maintenance  of  the  GMLA  will 
be  hmited  to  evaluation  of  missile  components  utilizing  BIT  capability  with  the  MTD  and 
examination  of  the  GMLA  for  evidence  of  moisture  and  serviceability.  The  unserviceable 
GMLAs  will  be  evacuated  to  depot  and  will  be  repaired  at  depot  utilizing  existing  depot 
plant  equipment,  which  has  the  capability  to  fault  isolate  to  the  Printed  Wired  Assembly 
(PWA)  level.  Repair  of  the  missiles  will  be  accomplished  by  replacement  of  major 
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assemblies,  subassemblies,  and/or  components  of  subassemblies.  In  addition  to  those 
unscheduled  repair  activities,  the  fielded  missiles  will  be  exposed  to  scheduled  periodic 
inspection,  test  and  rq)air  if  required  at  depot  level,  as  part  of  the  missile  surveillance 
plan.  Spares/repair  parts  of  the  GMLA  will  be  stocked  at  depot  level.  Unit  level 
spares/repair  part  for  GS  maintenance  activities  described  above  will  be  stocked  in 
Anmiunition  Support  Companies. 

(2)  Missile  Test  Device  (MTD):  GS  maintenance  of  the  MTD 
will  be  performed  by  the  MOS  27  personnel  assigned  to  the  Ammunition  Support 
Companies.  The  Operator  utilizing  the  self-test  capability  of  the  MTD  will  fault-isolate  to 
the  sub  assembly  and/or  components  of  subassembly.  Repair  of  the  MTD  will  be 
performed  by  replacement  of  the  imserviceable  item.  The  unserviceable  items  will  be 
repaired  at  depot  level.  Additionally,  the  MTD  will  be  cahbrated  within  a  scheduled  time 
period. 


(3)  Training  Equipment:  The  GS  level  support  of  the  training 
equipment  will  be  performed  by  utilizing  MOS  55  personnel  assigned  to  the  ammunition 
support  compames,  and  most  of  the  maintenance  fiuiction  of  this  equipment  will  be 
performed  at  that  level.  The  depot  level  support  will  only  be  limited  to  major  overhauls 
and  modifications  if  required. 
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b.  Software  Support 


The  Post  Deployment  Software  Support  (PDSS)  of  ATACMS  lA  system 
will  be  performed  by  the  ARMY  Software  Support  Center  at  depot  level.  The  PDSS 
metrics  will  be  provided  in  CASA  model  inputs  section. 

B.  COST  ESTIMATION  METHODOLOGY 

In  order  to  develop  the  LCC  cost  estimate  and  to  conduct  cost  risk  (uncertainty) 
and  cost  sensitivity  analyses  of  the  ATACMS  lA  missile  system,  the  Cost  Analysis 
Strategy  Assessment  (CASA)  Version  2000c  Decision  Support  System  (DSS)  will  be 
utilized. 

CASA  was  developed  by  the  US  Army  Materiel  Command  Logistics  Support 
Activity  (USAMC  LOGSA),  and  designed  to  provide  support  in  the  decision-making 
process  for  program  managers  assigned  to  materiel  systems  acquisition  programs. 
Despite  numerous  LCC  estimation  software  models  being  available  in  market  place,  only 
a  few  have  capabilities  to  perform  supportability,  operational  availability,  and  cost 
uncertainty-related  analyses  that  help  program  managers  address  CAIV  issues  and 
optimize  system  design  during  system  development  stages.  However,  the  CASA  model 
is  ideal  for  conducting  such  trade-off  and  sensitivity  analyses  as  well  as  cost  risk 
(uncertainty)  analyses.  The  CASA  model  addresses  the  LCC  of  the  objective  system 
including  RDT&E,  EMD  and  Production,  the  learning  and  production  rate  curves,  and  the 
entire  operational  Hfe  during  which  the  system  is  supported  in  the  field.  Virtually,  every 
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cost  associated  with  the  system  is  covered  by  CASA,  whether  one-time,  recurring,  or 


annual. 


The  CASA  model  utilizes  a  Monte  Carlo  simulation  technique  in  order  to 
simulate  system,  and/or  subsystem  failures;  elapsed  maintenance  times,  turn  around 
times,  logistics  delay  times,  and  cost  distribution  functions,  etc.  However,  the  CASA 
model  has  only  four  kinds  of  statistical  distribution  functions  in  its  library;  constant, 
uniform,  triangular,  and  normal  distributions.  The  exponential,  Poisson,  and  other  useful 
statistical  distribution  functions  are  excluded;  this  can  be  regarded  as  one  of  the 
drawbacks  of  the  model.  However,  if  large  numbers  of  systems,  or  .subsystems  are 
considered  in  the  LCC  estimation  and  analysis,  and  the  estimation  process  involves  a 
summation  of  different  statistical  distributions;  the  smnmation  process  results  tend  to 
approach  a  normal  distribution  due  to  the  Central  Lumt  Theorem  discussed  previously, 
and  the  drawbacks  of  the  model  are  off-set. 

The  CASA  model  has  the  inherent  capability  to  consider  and  evaluate  reliability 
growth  or  degradation  of  system  or  sub-systems,  and  their  impact  on  system  LCC,  if 
applicable.  This  capability  of  the  model  enables  the  PMO  to  effectively  model  the 
“bathtub”  behavior  of  system  hardware  components’  failure  rates,  and  conduct  reliability 
trade-off  analyses  for  the  specified  system. 

For  software  development  and  PDSS  activity  costs,  the  CASA  model  utilizes  a 
modified  version  of  Constructive  Cost  Model  (CoCoMo)  as  the  software  effort  estimating 
methodology.  The  modified  CoCoMo  model  utilizes  lines  of  source  code  and  other 
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adjustment  factors  such  as  program  complexity,  language  level,  and  diversity  as  inputs 
and  turns  them  into  required  man-months  of  efforts. 

Additionally,  the  CASA  model  has  capabilities  that  enable  the  PM  to  calculate 
spares  requirements  for  the  desired  service  levels  for  each  maintenance  echelon,  and 
evaluate  the  operational  availability  of  the  system.  The  operational  availability  module  of 
the  CASA  utilizes  two  different  approaches  for  operational  availability  assessments.  The 
operational  availability  optimization  method  determines  the  maximum  operational 
availability  of  the  system  within  given  constraints  and  adjusts  the  spares  layout  to  achieve 
the  maximum  feasible  operational  availability.  The  other  method,  which  is  called  target 
value  method,  enables  the  analyst  to  asses  the  spares  requirements  within  the  given 
support  structure  in  order  to  realize  the  target  operational  availability  value  for  the 
system. 

The  CASA  model  performs  the  LCC  estimation  of  the  system  imder  consideration 
through  a  summation  process  with  approximately  82  algorithms.  The  model  has  192 
variables,  most  of  which  are  optional  inputs  that  a  cost  analyst  can  tailor  to  the  specific 
needs  of  the  program.  However,  the  CASA  model  does  not  have  the  capability  to 
develop  Cost  Estimation  Relationships  (CER)  utilizing  comparable  system  cost  data, 
rather  it  requires  the  analysts  to  develop  CERs  utilizing  regression  techniques  first, 
estimate  expected  cost  figures’  distributions  for  sub-systems,  and  plug  those  numbers  into 
the  model.  If  the  CASA  model  had  been  designed  to  have  a  regression  module,  it  would 
have  been  a  very  robust  tool  for  the  analysts.  In  this  thesis;  the  cost  elements  such  as 
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RDT&E  costs,  base  unit  production  costs,  learning  and  production  rates  have  been  either 
derived  from  ATACMS  lA  CARD,  Selected  Acquisition  Reports  (SAR),  or  assumed  by 
the  author  utilizing  ATACMS  I  cost  data,  since  developing  and  validating  those  kind  of 
CERs  is  beyond  the  scope  of  the  thesis. 

C.  ESTIMATION  ASSUMPTIONS  AND  CASA  MODEL  INPUTS 

1.  Estimation  Assumptions 

First,  all  the  cost  figures  in  the  LCC  development  model  are  fictitious;  they  are 
generated  by  guidance  from  ATACMS  lA  CARD  document  and  based  on  reasonable 
judgments  by  the  author.  Since,  one  of  the  objectives  of  the  thesis  is  to  explore  the 
effects  of  system  performance  parameters  such  as  MTBF,and  MTTR  on  system  LCC  and 
operational  availability,  the  objective  will  be  realized  regardless  of  the  fictitiousness  of 
cost  figures. 

As  stated  in  previous  sections,  all  the  costs,  except  launcher  operator  initial 
orientation  traimng  costs,  associated  with  M270A1  Launcher  are  ignored  since  the 
deployment  of  the  missile  system  will  not  incur  additional  costs  associated  with  launcher. 
The  only  additional  cost  will  be  modification  of  launcher  software  modules,  and  the  costs 
associated  with  launcher  software  modification  efforts  are  included  in  initial  software 
development  costs. 

Although  the  total  number  of  acquired  systems  and  fielding  schedule  are  derived 
from  the  actual  acquisition  schedule  for  the  program,  the  numbers  of  General  Support 
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units  and  Depots  are  fictitious.  It  is  assumed  that  there  are  10  General  Support  locations, 
each  of  which  supports  80  missiles,  and  2  Depot  facilities,  each  of  which  supports  380 
units.  The  production  and  deployment  schedules  are  provided  in  model  inputs. 

Since  the  ATAMS  LA  is  a  missile,  and  required  to  be  mission  ready  at  all  times 
diuing  deployment,  it  is  assumed  that  the  operations  would  be  24  hours  per  day,  even  if 
the  missile  were  in  a  storage  mode.  In  addition,  it  is  assumed  that  the  operator-required 
portion  of  this  time  is  0,  since  there  are  no  operators  associated  with  the  missile  itself. 
The  operators  are  associated  with  MLRS  launchers. 

The  slope  of  the  learning  curve  and  slope  of  the  production  rate  associated  with 
ATACMS  lA  production  are  assumed  to  be  .90  and  .95,  respectively.  In  sensitivity 
analysis,  the  rate  changes  and  their  prospective  effects  on  LCC  will  be  evaluated 
separately. 

2.  CASA  Model  Inputs 

The  CASA  Model  inputs  are  provided  in  Appendix  A. 

D.  CASA  RESULTS  AND  ANALYSIS 

1.  LCC  Cost  Estimation  Results 

Ih  this  subsection,  the  percentage  distribution  of  the  LCC  major  elements  of 
missile  system,  which  are  RDT«&E,  Acquisition,  and  O&S  costs  are  discussed.  As 
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dq)icted  in  Ihe  Figure  17,  the  LCC  major  elements  are  distributed  as  15%,  44%,  and  41% 
for  RDT&E,  Acquisition,  and  O&S  costs,  respectively. 


As  discussed  previously;  the  RDT&E  costs  cover  all  the  efforts  and  cost 
commitments  that  are  related  to  development  of  the  system,  whereas  die  acquisition  costs 
cover  all  the  cost  elements  that  are  incurred  to  manufacture,  and  to  field  die  system  with 
required  support  equipment,  training  equipment,  documentation,  and  initial  spares,  hiitial 
spare  requirements  are  calculated  tbrough  assumed  confidence  levels  at  maintenance 
echelons,  which  are  90%  for  General  Support  Level  and  95%  for  depot  level. 
Additionally,  the  acquisition  costs  include  the  initial  software  development  and  initial 
training  costs.  The  interesting  tiling  in  distribution  of  Acquisition  cost  elements  into 
lower  level  categories  is  that  initial  software  development  efforts  constitute  a  significant 
portion  of  the  system  acquisition  costs,  which  is  approximately  36%  of  total  acquisition 
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costs  despite  conservative  assumptions  being  made  for  software  development  efforts.  As 
stated  in  CASA  inputs,  the  initial  trairring  requirements  are  classified  as  operator 
orientation,  GS  personnel  training,  and  Depot  personnel  training.  O&S  costs  cover  all  the 
efforts  and  cost  commitments  in  order  to  sustain  the  system  in  the  field,  including  the 
software  maintenance,  reciirring  training,  and  recurring  documentation  revision  costs. 
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Figure  18:  ATACMS  lA  Annual  Cost  Outlay  in  Constant  2001  Dollars 

[Source  Data:  Appendix  B] 


Figure  19:  ATACMS  lA  luflated  Annual  Cost  Outlays  [Source  Data:  Appendix  B] 

The  detailed  figures  for  file  CASA  model  LCC  estimation  for  ATACMS  lA  are 
provided  in  Appendix  B. 

2.  Sensitivity  Analysis 

hi  order  to  evaluate  the  marginal  effects  of  system  cost  drivers  and  system 
supportability  performance  parameters  on  system  LCC  and  operational  availability,  eight 
types  of  sensitivity  analysis  will  be  conducted.  These  evaluations  will  enable  the 
decision-makers  in  system  acquisition  and  support  environments  to  make  informed 
decisions  on  alternate  system  configurations,  acquisition  strategy  and  schedule,  and 
structuring  the  system  support  environment. 

First  five  of  these  analyses,  which  are  MTBF,  MTTR,  Unit  Cost,  Tum-Over  Rate, 
and  Spares  TAT  sensitivity  analyses,  are  conducted  to  evaluate  tiieir  marginal  effects  on 
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estimated  ICC  for  the  system.  The  following  two  analyses,  which  are  Learning  and 
Production  Rate  Curve  sensitivity  analyses,  are  performed  to  evaluate  the  changes  in  the 
system  acquisition  costs  wh«Q  the  assumed  learning  and  production  rate  slopes  are 
changed.  The  author  of  the  thesis  preferred  to  perform  sensitivity  analyses  for  the  learning 
and  production  rate  slopes  against  the  system  acquisition  costs  rather  than  sj^tem  LCC, 
since  both  of  the  cost-drivers  are  related  to  system  production  specifically.  The  last 
sensitivity  analysis,  which  is  operational  availability  sensitivity  analyses,  is  conducted  to 
evaluate  the  efforts  of  MTBF,  Spares  Confidence  Levels  (CL),  and  System-Level 
Maintenance  Elapsed  Time  (MET)  on  system  operational  availability.  System-Level 
MET  consists  of  system  active  maintenance  time,  adrnmistrative  delay  time,  and  logistics 
delay  time  for  system  maintenance  activities.  System  active  maintenance  time,  that  is  a 
weighted  mean  value  of  MTTRs  of  the  system  for  corrective  and  preventive  maintenance 
actions,  is  primarily  a  system  design  decision;  but  the  other  ingredients  of  MET,  which 
are  administrative  delay  time  and  lo^stics  delay  times  that  includes  transportation  of  the 
system  to  applicable  maintaoance  echelon,  are  related  to  the  effectiveness  and  efficiency 
of  the  system  support  environment  However,  during  the  ^stem  design  perio  d,  the  i^stem 
developers  can  perform  an  effective  supportability  analysis  for  the  concaved  system 
design  tiiat  enables  the  system  to  exploit  the  current  logistics  environment  in  most 
efficient  and  effective  way. 

In  the  following  sub  subsections,  the  results  of  those  sensitivity  analyses  are 
discussed.  The  data  related  to  these  sensitivity  analyses  are  provided  in  Appendix  C. 
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MTBF  Sensitivity  Analysis 


a. 

As  discussed  in  the  previous  sections,  the  MTBF  performance  parameter 
denotes  the  time  period  in  which  system  and  its  sub-systems  or  components  functions  in 
tiheir  intended  ways  without  a  failure.  The  decrease  in  MTBF  of  the  system  or  its 
components  affects  systems  LCC  through  an  increased  quantity  of  spare  parts 
requirement  at  given  confidaice  levels,  increased  amount  of  maintenance  work  required, 
and  increased  quantity  of  support  equipment  requirements  and  utilization. 

As  seen  in  Figure  20,  the  relationship  between  MTBF  and  system  LCC  is 
negative  in  nature;  the  increase  in  MTBF  decreases  system  LCC  or  vice  verse.  However, 
if  the  system  design  and  technology  is  the  state-of-the-art-of  available  technology,  then  it 
generally  requires  investment  in  research  and  development  activities  to  increase  the 
MTBFs  of  the  system  and  its  subsystems  or  components.  This  requirement  for  pushing 
the  edge  of  technology  may  increase  system  acquisition  costs. 


Percent  of  baseline 


Figure  20:  ATACMS  lA  LCC  Sensitivity  to  MTBF  [Source  Data:  Appendix  CJ 
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As  is  clear  jBx)m  &e  Figure  20,  the  marginal  benefits,  in  terms  of  system 
LCC  reductions,  of  the  improvements  in  MTBF  decreases  as  the  level  of  improvement 
increases.  For  example;  increasing  the  MTBF  from  its  70%  to  the  current  level  reduced 
the  system  LCC  by  $105,000,000  which  means  that  tiie  average  LCC  savings  is 
$3,500,000  per  one  percent  improvement  in  MTBF,  whereas  increasing  file  baseline 
MTBF  to  its  140%  value  promises  LCC  savings  about  $70,000,000  which  translates 
$1,750,000  saving  per  one  percent  of  improvement  on  average.  This  behavior  of  the 
curve  obeys  the  general  economics  principle  of  deoreasing  marginal  benefits,  and  may 
provide  guidance  to  the  decision-makers  in  allocating  resources  for  RDT&E  activities  and 
system  reliability  improvement  programs. 

b.  MTTR  Sensitivity  Analysis 

MTTR  refers  to  maintainability  of  tiie  system,  sub-systems  and  their 
components.  MTTR  ajBfects  system  LCC  costs  throu^  system  maintenance  labor  costs. 
As  it  is  evident  from  the  Fi^rre  21;  there  is  positive  relationship  between  system  or 
subsystem  MTTR  values  and  the  ^tem  LCC,  which  states  tiiat  as  the  MTTR  values  are 
increases,  the  system  LCC  cost  increasKi  pioportionately. 
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Figure  21 :  ATACMS  lA  LCC  Sensitivity  to  MTTR  [Source  Data:  Appendix  C] 

As  depicted  in  the  Figure  21,  the  sensitivity  of  LCC  to  MTHl  values  of 
the  system  and  sub-systems  or  &eir  components  is  calculated  ^proximately  as  SI 00,000 
per  one  percent  change  in  die  baseline  values. 

c.  Spares  Unit  Cost  Sensitivity  Analysis 

Spares  unit  cost  affects  LCC  through  both  acquisition  costs  and  O&S 
costs.  The  sensitivity  analysis  conducted  to  assess  the  effects  of  probable  escalation  rates 
for  unit  cost  of  spares  and  provide  an  enabling  tool  for  the  negotiations  with  contractors 
for  either  system  acquisition,  warranty  discussions,  or  different  types  of  system  support 
agreements. 


As  pointed  out  in  the  Figure  22,  tiiere  is  a  positive  relationship  between 
the  spares  umt  costs  and  the  S3iStem  LCC;  the  marginai  effect  of  1%  increase  on  spare  unit 
costs  is  approximately  $160,000  on  the  system  LCC.  The  sensitivity  chart  reflects  the 
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average  changes  on  ^ares  basehne  cost  figures  rather  than  an  item-by-item  basis,  hi 
order  to  evaluate  the  changes  on  the  baseline  unit  cost  figures  for  each  spare  item  more 
^ecifically,  a  sensitivity  analysis  on  item-by-item  basis  should  be  conducted.  However, 
the  author  did  not  perfonn  that  kind  of  analysis,  because  of  space  limitations. 


Figure  22:  ATACMS  lA  LCC  Sensitivi^  to  Spares  Unit  Cost  [Source  Data:  Appendix  CJ 


d.  Turn  Over  Rate  (T OR)  Sensitivity  Analysis 


TOR  refers  to  the  annual  turn  over  rate  of  the  anployees  associated  with 
General  Si5)port  and  Depot  level  maintenance  of  the  ATACMS  lA  missile.  The  launcher 
operator  TOR  is  excluded  Jfiom  this  analysis;  since  all  the  costs  associated  with  MLRS 
launcher  are  excluded  from  LCC  estimation  and  relevant  analyses,  as  stated  in  the 
assumptions  section. 


The  annual  TOR  of  the  maintoiance  and  support  employees  affects  system 
LCC  throu^  recurring  training  requirements.  As  tibe  TOR  increases  1%  of  baseline 
value,  the  system  LCC  increases  by  approximately  S10,000.  This  analysis  may  prove  to 
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be  a  valuable  tool  for  the  PMs  and  support  facilities  managers  in  developing  strategies 
and  allocating  resources  to  employ  those  strategies  in  order  to  increase  the  retention  rates 
of  employees  associated  with  the  system. 


660 

659.5 
o  659 

O 

o 

2  658.5 
^  658 

657.5 
657 


Figure  23:  ATACMS  LA  LCC  Sensitivify  to  Maintenance  Labor  TOR 
[Source  Data:  Appendix  C] 

e.  Spares  TAT  Sensitivity  Analysis 

The  ^ares  Turn  Around  Time  (TAT)  refers  to  the  time  period  that  is 
closed  to  replace  a  spare  unit,  which  is  used  to  maintain  the  sj^em,  either  by  repairing 
die  unserviceable  one  or  purchasing  a  new  spare  unit  As  the  spares  TAT  increases  on 
average,  die  initial  spares  requirements  increases  to  meet  the  confidence  levels 
throu^out  the  maintenance  echelons  or  vice  verse.  This  relationship  is  depicted  in  Figure 
24. 
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Figure  24:  ATACMS  lA  LCC  Sensitivity  to  Spares  TAT  (Source  Data:  Appendix  CJ 

As  the  chart  points  out,  1%  change  of  baseline  spares  TAT  increases  the 
system  LCC  approximately  by  $50,000  on  average.  The  ^ares  TAT  is  the  function  of 
spares  maintainability,  transportability,  the  eJBBciency  of  the  logistics  support 
infrastructure,  and  the  responsiven^s  of  the  organizations  associated  with  that  spares 
irnit.  Henceforth,  this  analysis  can  be  used  as  a  decision  enabler  in  evaluating 
maintainability  and  transportability  alternatives  for  the  system  and  its  spar^  units  during 
the  system  development  period,  and  evaluating  the  cost  and  benefits  of  improving  the 
efficiency  of  the  system  logistics  infrastructure. 

f.  Learning  Curve  Sensitivity  Analysis 

Learning  curves  are  associated  wifli  recurring  production  activities, 
therefore  the  sensitivity  analysis  is  conducted  to  evaluate  tiie  effects  of  changes  in 
assumed  learning  rates  hi  sj^tem  acquisition  costs.  As  stated  previously,  the  assumed 
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slope  of  learning  curve  for  the  system  production  is  90%.  In  the  sensitivity  analysis, 
system  acquisition  costs  are  calculated  for  the  fractions  of  the  baseline  learning  curve 
slope.  The  Hgure  25  depicts  the  behavior  of  system  acquisition  costs  for  the  changes  of 
baseline  learning  rate. 


o 


Figure  25:  ATACMS  lA  Acquisition  Cost  Sensitivity  to  The  Slope  of  Learning  Curve 

[Source  Data:  Appendix  C] 

The  chart  shows  that  the  acquisition  costs  increase  at  an  increasing  rate,  as 
the  slope  of  learning  curve  increases  that  is  the  learning  rate  for  the  system  recurring 
production  activities  decreases.  The  learning  curve  analysis  provides  leverage  for  cost 
analysis  of  the  contractors’  production  cost  proposals,  and  enables  the  PMO  to  prepare 
budgeting  requests  and  program  cost  estimates  more  effectivelv.  Furthermore,  learning 
curve  analysis  proves  to  be  an  important  tool  in  evaluating  the  alternative  system 
production  schedules  through  assessment  of  their  effects  on  learning  rates. 
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Production  Rate  Curve  Sensitivity  Anafysis 


Similar  to  learning  curves,  the  production  rate  curves  are  associated  with 
system  production  activiti^;  generally  increased  production  rates  decrease  average  cost 
of  manufachired  quantities  through  increased  capacity^  utilization  and  reduction  of 
production  overhead  costs  and  non-recurring  costs  per  manufactured  unit.  However,  this 
underlying  assumption  holds  within  the  botmdaries  of  sustainable  production  capacity 
utilizations,  beyond  those  points  the  average  unit  costs  tend  to  increase  because  of 
required  cost  commitments  for  capacity  increases  and  hi^a:  inventory  holding  costs. 

The  slope  of  production  rate  curve  refers  to  the  degree  of  logarithmic 
relationship  between  production  rate  and  system  manufacturing  costs;  the  relationship  can 
be  described  such  as  the  slope  of  the  production  rate  curve  gets  hi^er  value,  the  effects 
of  production  rate  on  system  production  costs  get  smaller.  In  order  to  test  that 
assumption,  and  to  assess  flie  eflfecte  of  different  production  rates  on  the  production  costs 
of  the  so-called  sj^em  a  sensitivity  analysis  is  conducted  for  the  Motions  of  baseline 
production  rate  slope,  which  is  assumed  to  be  95%. 

Figure  26  provided  below  depicts  the  changes  in  the  system  acquisition 
cost  estimates  for  different  values  of  production  rate  slope.  As  is  clear  from  tiie  Figure 
26,  the  system  acquisition  cost  estimate  grows  at  an  increasing  rate  as  the  slope  of  the 
production  rate  curve  increases.  The  assessment  of  the  eff«;ts  of  different  production  rate 
slopes  on  system  acquisition  costs  enables  the  acquiring  agencies  to  evaluate  the 
contractor’  cost  proposals,  develop  production  cost  estimates  for  the  system  more 
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effectively,  and  structure  the  system  acquisition  and  production  schedule  in  a  way  that 
optimizes  system  production  costs. 
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Figure  26:  ATACMS  lA  Acquisition  Cost  Sensitivity  to  The  Production  Rate  Slope 

[Source  Data:  Appendix  C] 

h.  Operational  Availability  Sensitivity  Analysis 

As  discussed  in  previous  chapters,  fee  operational  availability  of  fee 
system  refers  to  fee  probability  that  fee  system  under  consideration  would  be  available  in 
operational  status  when  needed  during  its  operational  life.  The  parameters  of  operational 
availability  are  system  MTBF,  and  system  level  maintenance  el^sed  time  (MET),  which 
includes  system  MTTR,  logistics  down  time  that  refers  to  fee  responsiveness  of  logistics 
system  including  transportation  time,  and  administrative  delay  time  feat  refers  to 
responsiveness  of  the  organization  at  which  fee  system  is  operated.  In  order  to  assess  fee 
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marginal  effects  of  those  parameters  on  ^stem  operational  availability,  sensitivity 
analyses  are  conducted  for  each  of  those  parameters.  Figures  27,  28,  and  29  exhibit  the 
results  of  those  sensitivity  analyses. 


Figure  27,  which  reflects  operational  availability  sensitivity  to  the  system 
level  MTBF,  depicts  that  the  operational  availability  of  the  s)^em  increases  at  a 
decreasing  rate  as  the  MTBF  increases.  In  other  words,  there  is  a  decreasing  marginal 
benefit,  m  terms  of  operational  availability,  of  increasing  the  system  level  MTBFs  either 
by  pushing  the  ^ge  of  technology  or  introducmg  redundancy  to  the  system  at  lower 
levels  of  the  system  hierarchy.  This  sensitivity  analysis  provides  a  j&amework  for 
commitments  for  RDT&E  ejBforts  for  reliability  improvements,  and  enables  the  system 
developers  to  assess  the  effects  of  alternative  system  designs  on  operational  availability. 
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Figure  27:  ATACMS  lA  Operational  Availability  Sensitivity  to  MTBF 

(Source  Data:  Appendix  Cj 
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Figures  28  and  29  reflect  the  sensitivity  of  operational  availability  to 
spares  Confidence  Levels  (CL)  throughout  maintenance  echelons  and  system  level 
maintenance  elapsed  time  that  is  discussed  above  respectively. 
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Figure  28:  ATACMS  lA  Operational  Availabflity  Sensitivity  to  Spares  CL 

[Source  Data:  Appendix  CJ 

As  clearly  expressed  in  the  chart,  increasing  spares  confidence  levels, 
which  means  increasing  the  quantity  of  spare  parts  throughout  maintenance  echelons, 
beyond  90  %  of  baseline  values,  which  are  90%  and  95%  for  General  Support  and  Depot 
levels  respectively,  does  not  yield  a  significant  increase  in  operational  availability  for  the 
s>^em.  Furthermore,  this  sensitivity  analysis  shows  that  there  has  been  only  a  .0102 
improvement  cumulatively  in  the  operational  availability  of  the  system  by  increasing  the 
confidence  levels  fi-om  50%  of  baseline  valu^  to  the  100%  of  baseline  values.  These 
insists  firom  that  sensitivity  analysis  provide  valuable  guidance  to  establish  an 
^propriate  confidence  level  for  each  of  the  maintenance  echelons,  and  enables  flie  PMO 
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to  assess  cost  ejBfaitivCTiess  of  the  increasing  spares  conjSdence  levels  or  increasing  spares 
quantities  associated  with  the  system. 


0.98 
0.96 
0.94 
0.92  I 
0-9  J 

0.88  I 

0.86  O 
0.84 
0.82 

250  200  150  100  50  0 

MET  as  Percent  of  Baseline 


Figure  29:  ATACMS  lA  Operational  Availability  Sensitivity  to  System  Level  MET 

[Source  Data:  Appendix  CJ 

Figure  29  points  out  the  results  of  the  sensitivity  analysis  conducted  to  test 
the  operational  availability  sensitivity  to  system  level  maintenance  elapsed  time,  which 
was  discussed  previously.  As  depicted  clearly  in  the  chart,  decreasing  system  level  MET 
promises  significant  improvements  in  operational  availability  of  the  system.  For  instance, 
decreasing  baseline  value  of  system  level  MET  by  half  (that  is  50%)  improves  operational 
availability  to  .961  fi-om  .90.  As  discussed  previously,  the  ingredients  of  system  level 
MET  are  system  level  MTTR,  logistics  delay  time,  and  administrative  delay  time;  and 
only  one  of  those  ingredients,  which  is  MTTR,  is  constrained  by  system  design,  the  others 
are  predominantly  determined  by  the  effectiveness  of  the  lo^stics  si^port  infiastructure 
of  the  environment  in  which  the  system  operates.  Therefore,  improving  effectiveness  of 
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the  logistics  system  and  eliminating  non-value  adding  activities  in  fee  system  support 
process,  promise  permanent  significant  improvements  in  fee  operational  availability  of 
fee  system. 

Furthermore,  when  we  compare  fee  results  of  fee  MET  sensitivity  analysis 
wife  the  results  of  fee  confidence  level  sensitivity  analysis;  it  seems  evident  feat 
improving  the  efSciency  and  effectiveness  of  logistics  support  organizations  and 
processes  is  a  more  successful  strategy  to  improve  operational  availability  of  the  system 
than  merely  increasing  spares  confidence  levels,  in  other  words,  increasing  spare 
quantities  throu^out  fee  maintenance  echelons. 

3.  Uncertainty  Analysis 

hi  order  to  assess  the  risk  associated  wife  fee  assumed  cost  structure  for  fee 
s}^em,  an  uncertainty  analysis  is  conducted  utilizing  a  Monte  Carlo  simulation  technique 
which  is  embedded  in  fee  CASA  cost  estimating  and  analysis  model.  The  CASA  model’s 
risk  analysis  model  has  been  limited  to  a  maximum  200  simulation  runs,  therefore  fee 
ATACMS  lA  LCC  cost  risk  analysis  is  limited  to  200  simulation  runs.  Although  200 
simulation  runs  is  a  small  number  to  determine  ^propriate  distribution  and  probabilities 
of  fee  potential  LCC  for  fee  system,  it  gives  an  insight  into  fee  cost  risk  behavior  of  fee 
system.  In  Figures  30  and  31,  fee  frequencies  and  cumulative  probabilities  of  fee 
potential  values  for  system  LCC  are  provided,  respectively.  The  risk  analysis  results  data 
is  provided  in  Appendix  D. 
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As  discussed  in  Chapter  H,  the  LCC  estimation  process  inherently  includes  many 
uncertainties;  therefore  the  probability  of  realization  of  a  point  estimate  is  almost  zero, 
regardless  of  the  estimating  methodology  utilized.  Henceforth,  it  is  a  prudent  approach  to 
express  the  cost  estimates  with  flieir  respective  probabilities  or  with  their  probability 
distribution  type  and  parameters  such  as  mean  value,  standard  deviation,  etc. 


Figure  30:  ATACMS  lA  LCC  Frequency  (200  Runs) 


[Source  Data:  Appendix  D] 
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V.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  CONCLUSIONS 

The  acquisition  of  major  systems  requires  long  term  cost  commitments  by  the 
acquiring  organizations,  thus  the  resource  allocation  decisions  must  be  based  on  life-cycle 
oriented  analyses  of  so-called  systems  rather  than  analysis  of  the  costs  associated  with  up- 
jfront  costs. 

As  is  discussed  in  ATACMS  lA  case,  system  sustainment  costs  constitute  a 
significant  portion  of  system  LCC  costs,  thus  system  development  efforts  and  source 
selection  decisions  in  an  acquisition  environment  must  be  based  on  Total  Ownership  Cost 
evaluations  of  the  alternative  system  solutions.  Additionally,  the  implementation  of 
alternative  business  practices  such  as  IPPD,  and  Concurrent  Engineering  help  the  system 
developers  and  acquisition  practitioners  reduce  the  TOC  of  the  system  and  increase  the 
operational  availability  of  the  system.  Furthermore,  the  PMs  should  develop  cost 
reduction  and  operational  availability  improvement  strategies,  not  only  considering  the 
system  itself,  but  also  considering  the  system  and  its  support  environment  as  a  whole, 
otherwise  these  cost  reduction  and  operational  availability  improvement  efforts  will  not 
be  as  efficient  and  effective  as  expected. 

The  acquisition  process,  system  development  efforts,  and  cost  estimation  process 
which  help  decision  makers  allocate  valuable  resources  to  a  program,  or  among  programs 
have  inherent  uncertainties  about  future  or  expected  program  outcomes.  Henceforth,  the 
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cost  uncertainty  analyses  about  the  expected  program  costs  help  the  PMs  uncover  the 
costs  risks  associated  with  the  program,  develop  realistic  program  cost  estimates,  and  take 
appropriate  measures  such  as  PM’s  management  reserve  proactively,  thus  the  program 
will  continue  without  significant  breaks  resulting  from  the  unavailability  of  funds. 

B.  RECOMMENDATIONS 

The  cost  estimation  and  analysis  of  the  estimate  results  for  ATACMS  lA  system 
have  been  performed  by  utilizing  the  CASA  cost  estimation  tool  developed  by  the  US 
Army  Materiel  Command. 

Although  the  CASA  model  is  very  useful  tool  for  developing  LCC  estimates, 
conducting  sensitivity  and  uncertainty  analyses  by  evaluating  different  system  cost  and 
supportability  performance  parameters  and  their  impacts  on  system  LCC  and  operational 
availability;  the  CASA  should  be  improved  in  a  way  that  enhances  those  capabilities, 
integrates  the  cost  estimation  techniques  to  the  CASA  such  as  incorporation  of  a  data 
analysis  and  regression  module,  and  includes  all  the  statistical  distribution  functions, 
which  are  relevant  to  system  performance  and  cost  behaviors. 
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APPENDIX  A.  CASA  MODEL  INPUTS 


no 


Ill 


Hukiisands  of  New/Modified  Source  L 


Tliioiisaiids  of  Reused  Source  Lines: 


Uieusands  of  Retained  Source  Lines: 


Software  Development  Labor  Rate  ($ 


Tear  Dollars  Expressed  ibr  SDLR 


Portion  of  initial  Software  Developmentby  Year 


1994 

1995 

1996 

1997 

40% 

50% 

8% 

2% 

! 

! 

1 

i 

NOTE:  S  W  MAINTENACE  EFFORTS  ARE  EXPRESSED 

|BY  FRACTION  OF  INTIAL  EFFORTS  BY  YEAR. 
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APPENDIX  B.  ATACMS  lA  LCC  ESTIMATION  RESULTS 


ATACMS  lALCC  Estimation 

TOTAL  LIFE  CYCLE  COST 

Total  EDT&E  Cost 

$95,657,000 

Total  Acquisition  Cost 

$293,927,288 

Total  Operation  and  Support  Cost 

$269,103,010 

TOTAL  LIFE  CYCLE  COST 

$658,687,298 

KDT&E  Cost 

Distribution 

Research  &  Development 

29% 

$27,740,530 

Demonstration  and  Validation 

12% 

$11,478,840 

System/Project  Management 

19% 

$18,174,830 

System  Test  &  Evaluation 

15% 

$14,348,550 

Training 

3% 

$2,869,710 

Data 

4% 

$3,826,280 

Software  Center 

17% 

$16,261,690 

Other 

1% 

$956,570 

Total  RDT&E  Cost 

$95,657,000 

Operation  and  Support  Costs 

General  Support 

Depot 

Total 

Repair  Labor 

$1,113,077 

$97,808,670 

$98,921,747 

Support  Equip  l^aint 

$0 

$18,518,333 

$18,518,333 

Recurring  Trainmg 

$58,854 

$1,018,875 

$1,077,729 

Repair  Prts  and  Mtl 

$2,225,708 

$87,066,942 

$89,292,651 

Consumables 

$222,571 

$8,706,694 

$8,929,265 

Condemnation  Spares 

$32,279 

$8,918,493 

$8,950,772 

Tech  Data  Revisions 

$11,667 

$11,667 

$23,333 

Transportation 

$3,782,680 

$4,180,716 

$7,963,397 

Recrring  Facilities 

$1,803,333 

$6,666,667 

$8,470,000 

Re  erring  Item  Mgmt 

$272,833 

$171,200 

$444,033 

Sftware  Maintenance 

$0 

$26,511,749 

$26,511,749 

TOTALO&SCOST 

$9,523,003 

$259,580,007 

$269,103,010 

(NOT  CONSIDERING  WARRAISTTY) 

1  1 
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APPENDIX  C.  SENSITIVITY  ANALYSIS  RESULTS 
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APPENDIX  D.  COST  RISK  ANALYSIS  RESULTS 


Ilcc  monte  carlo  results 

Minmiutt 

Maximunt 

Mean 

Standard  Deviation 

$  674,291.920.00 

$  654,988,589.02 

$  9.192,608.21 

LCC  Frequency  Table 

LCC  Cumulative  Distributioi 

Cell  Mid  Point 

Frequency 

Cell  End  Point 

Cumulative  Preb^ility 

iMiiiimifni 

6 

636.639,051.87 

0.03 

$  638.087,239.11 

5 

639,535.426.34 

0.06 

MwmmmmM 

10 

642,431,800.81 

0.11 

12 

645,328.175.29 

0.17 

iMf'i  i^iiPii 

16 

648,224,549.76 

0.25 

$  649,672,73659 

24 

651.120524.23 

037 

$  652,569,111.46 

16 

654,017,298.70 

0.45 

$  655.465,485.94 

22 

656,913,673.17 

0.56 

iMiiPimiFii 

18 

659.810,047.64 

0.65 

$  661.258,234.88 

23 

662,706,422.12 

0.76 

18 

665,602,796.59 

0.85 

$  667,050,983.82 

21 

668,499,171.06 

0.96 

$  669,947,358.29 

7 

671.395,545.53 

0.99 

$  672.843,732.77 

2 

674291.920.00 

1.00 
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